[PATCH 2/2] iommu/mediatek: Alloc building as module
The IOMMU in many SoC depends on the MM clocks and power-domain which
are device_initcall normally, thus the subsys_init here is not helpful.
This patch switches it to module_platform_driver which allow the
driver built as module.
Correspondingly switch the config to tristate.
Signed-off-by: Yong Wu
---
drivers/iommu/Kconfig | 2 +-
drivers/iommu/mtk_iommu.c | 16
2 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index bc93da48bed0..74f3e15edc14 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -349,7 +349,7 @@ config S390_AP_IOMMU
is not implemented as it is not necessary for VFIO.
config MTK_IOMMU
- bool "MTK IOMMU Support"
+ tristate "MediaTek IOMMU Support"
depends on ARCH_MEDIATEK || COMPILE_TEST
select ARM_DMA_USE_IOMMU
select IOMMU_API
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 6ecc007f07cd..a73ff3e20480 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1079,16 +1080,7 @@ static struct platform_driver mtk_iommu_driver = {
.pm = _iommu_pm_ops,
}
};
+module_platform_driver(mtk_iommu_driver);
-static int __init mtk_iommu_init(void)
-{
- int ret;
-
- ret = platform_driver_register(_iommu_driver);
- if (ret != 0)
- pr_err("Failed to register MTK IOMMU driver\n");
-
- return ret;
-}
-
-subsys_initcall(mtk_iommu_init)
+MODULE_DESCRIPTION("IOMMU API for MediaTek M4U implementations");
+MODULE_LICENSE("GPL v2");
--
2.18.0
[PATCH 1/2] iommu/mediatek-v1: Alloc building as module
This patch only adds support for building the IOMMU-v1 driver as module.
Correspondingly switch the config to tristate.
Signed-off-by: Yong Wu
---
rebase on v5.12-rc2.
---
drivers/iommu/Kconfig| 2 +-
drivers/iommu/mtk_iommu_v1.c | 9 -
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 192ef8f61310..bc93da48bed0 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -364,7 +364,7 @@ config MTK_IOMMU
If unsure, say N here.
config MTK_IOMMU_V1
- bool "MTK IOMMU Version 1 (M4U gen1) Support"
+ tristate "MediaTek IOMMU Version 1 (M4U gen1) Support"
depends on ARM
depends on ARCH_MEDIATEK || COMPILE_TEST
select ARM_DMA_USE_IOMMU
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index 82ddfe9170d4..71370037083a 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -691,9 +692,7 @@ static struct platform_driver mtk_iommu_driver = {
.pm = _iommu_pm_ops,
}
};
+module_platform_driver(mtk_iommu_driver);
-static int __init m4u_init(void)
-{
- return platform_driver_register(_iommu_driver);
-}
-subsys_initcall(m4u_init);
+MODULE_DESCRIPTION("IOMMU API for MediaTek M4U v1 implementations");
+MODULE_LICENSE("GPL v2");
--
2.18.0
Re: linux-next: build warning after merge of the sound-asoc tree
On 3/23/21 11:13 AM, Stephen Rothwell wrote:
Hi all,
After merging the sound-asoc tree, today's linux-next build (powerpc
allyesconfig) produced this warning:
sound/soc/amd/acp-da7219-max98357a.c:684:28: warning: 'cz_rt5682_card' defined
but not used [-Wunused-variable]
684 | static struct snd_soc_card cz_rt5682_card = {
|^~
sound/soc/amd/acp-da7219-max98357a.c:671:28: warning: 'cz_card' defined but not
used [-Wunused-variable]
671 | static struct snd_soc_card cz_card = {
|^~~
Introduced by commit
7e71b48f9e27 ("ASoC: amd: Add support for RT5682 codec in machine driver")
Will add ACPI dependency in Kconfig and submit the supplement patch.
linux-next: build warning after merge of the v4l-dvb tree
Hi all,
After merging the v4l-dvb tree, today's linux-next build (htmldocs)
produced this warning:
Documentation/driver-api/media/camera-sensor.rst:147: WARNING: Error in
"c:function" directive:
1 argument(s) required, 0 supplied.
.. c:function::
int pm_runtime_get_if_in_use(struct device *dev);
Introduced by commit
c0e3bcb25390 ("media: camera-sensor.rst: fix a doc build warning")
--
Cheers,
Stephen Rothwell
pgpqSC44tkRva.pgp
Description: OpenPGP digital signature
linux-next: build warning in Linus' tree
Hi all,
Building Linus' tree, today's linux-next build (x86_64 allnoconfig)
produced this warning:
kernel/static_call.c: In function '__static_call_update':
kernel/static_call.c:153:18: warning: unused variable 'mod' [-Wunused-variable]
153 | struct module *mod = site_mod->mod;
| ^~~
Introduced by commit
698bacefe993 ("static_call: Align static_call_is_init() patching condition")
--
Cheers,
Stephen Rothwell
pgpB9INoHqX51.pgp
Description: OpenPGP digital signature
[PATCH] soc: mediatek: mmsys: Add mt8183 mmsys routing table
mt8183 has different routing registers than mt8173.
Signed-off-by: Hsin-Yi Wang
---
This patch is based on series ("soc: mediatek: Prepare MMSYS for DDP routing
using tables")[1]
and tested with mt8183 krand and mt8183 juniper device.
The register value is referenced from [2].
[1]
https://patchwork.kernel.org/project/linux-mediatek/cover/20210317181711.795245-1-enric.balle...@collabora.com/
[2]
https://patchwork.kernel.org/project/linux-mediatek/patch/1609815993-22744-6-git-send-email-yongqiang@mediatek.com/
---
drivers/soc/mediatek/mtk-mmsys.c | 2 ++
drivers/soc/mediatek/mtk-mmsys.h | 47
2 files changed, 49 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index c46d8ab8b0c2..16bb55b0463a 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -40,6 +40,8 @@ static const struct mtk_mmsys_driver_data
mt8173_mmsys_driver_data = {
static const struct mtk_mmsys_driver_data mt8183_mmsys_driver_data = {
.clk_driver = "clk-mt8183-mm",
+ .routes = mmsys_mt8183_routing_table,
+ .num_routes = ARRAY_SIZE(mmsys_mt8183_routing_table),
};
struct mtk_mmsys {
diff --git a/drivers/soc/mediatek/mtk-mmsys.h b/drivers/soc/mediatek/mtk-mmsys.h
index a760a34e6eca..c55baf5932b8 100644
--- a/drivers/soc/mediatek/mtk-mmsys.h
+++ b/drivers/soc/mediatek/mtk-mmsys.h
@@ -66,6 +66,28 @@
#define DPI_SEL_IN_BLS 0x0
#define DSI_SEL_IN_RDMA0x1
+#define MT8183_DISP_OVL0_MOUT_EN 0xf00
+#define MT8183_DISP_OVL0_2L_MOUT_EN0xf04
+#define MT8183_DISP_OVL1_2L_MOUT_EN0xf08
+#define MT8183_DISP_DITHER0_MOUT_EN0xf0c
+#define MT8183_DISP_PATH0_SEL_IN 0xf24
+#define MT8183_DISP_DSI0_SEL_IN0xf2c
+#define MT8183_DISP_DPI0_SEL_IN0xf30
+#define MT8183_DISP_RDMA0_SOUT_SEL_IN 0xf50
+#define MT8183_DISP_RDMA1_SOUT_SEL_IN 0xf54
+
+#define MT8183_OVL0_MOUT_EN_OVL0_2LBIT(4)
+#define MT8183_OVL0_2L_MOUT_EN_DISP_PATH0 BIT(0)
+#define MT8183_OVL1_2L_MOUT_EN_RDMA1 BIT(4)
+#define MT8183_DITHER0_MOUT_IN_DSI0BIT(0)
+#define MT8183_DISP_PATH0_SEL_IN_OVL0_2L 0x1
+#define MT8183_DSI0_SEL_IN_RDMA0 0x1
+#define MT8183_DSI0_SEL_IN_RDMA1 0x3
+#define MT8183_DPI0_SEL_IN_RDMA0 0x1
+#define MT8183_DPI0_SEL_IN_RDMA1 0x2
+#define MT8183_RDMA0_SOUT_COLOR0 0x1
+#define MT8183_RDMA1_SOUT_DSI0 0x1
+
struct mtk_mmsys_routes {
u32 from_comp;
u32 to_comp;
@@ -212,4 +234,29 @@ static const struct mtk_mmsys_routes
mmsys_default_routing_table[] = {
}
};
+static const struct mtk_mmsys_routes mmsys_mt8183_routing_table[] = {
+ {
+ DDP_COMPONENT_OVL0, DDP_COMPONENT_OVL_2L0,
+ MT8183_DISP_OVL0_MOUT_EN, MT8183_OVL0_MOUT_EN_OVL0_2L
+ }, {
+ DDP_COMPONENT_OVL_2L0, DDP_COMPONENT_RDMA0,
+ MT8183_DISP_OVL0_2L_MOUT_EN, MT8183_OVL0_2L_MOUT_EN_DISP_PATH0
+ }, {
+ DDP_COMPONENT_OVL_2L1, DDP_COMPONENT_RDMA1,
+ MT8183_DISP_OVL1_2L_MOUT_EN, MT8183_OVL1_2L_MOUT_EN_RDMA1
+ }, {
+ DDP_COMPONENT_DITHER, DDP_COMPONENT_DSI0,
+ MT8183_DISP_DITHER0_MOUT_EN, MT8183_DITHER0_MOUT_IN_DSI0
+ }, {
+ DDP_COMPONENT_OVL_2L0, DDP_COMPONENT_RDMA0,
+ MT8183_DISP_PATH0_SEL_IN, MT8183_DISP_PATH0_SEL_IN_OVL0_2L
+ }, {
+ DDP_COMPONENT_RDMA1, DDP_COMPONENT_DPI0,
+ MT8183_DISP_DPI0_SEL_IN, MT8183_DPI0_SEL_IN_RDMA1
+ }, {
+ DDP_COMPONENT_RDMA0, DDP_COMPONENT_COLOR0,
+ MT8183_DISP_RDMA0_SOUT_SEL_IN, MT8183_RDMA0_SOUT_COLOR0
+ }
+};
+
#endif /* __SOC_MEDIATEK_MTK_MMSYS_H */
--
2.31.0.rc2.261.g7f71774620-goog
Re: [kbuild-all] Re: include/linux/compiler_types.h:315:38: error: call to '__compiletime_assert_536' declared with attribute error: BUILD_BUG_ON failed: offsetof(struct can_frame, len) != offsetof(st
Hi Oliver and Rong,
This is an interesting and quite surprising issue!
On Tue. 23 mars 2021 at 11:54, Rong Chen wrote:
> On 3/23/21 12:24 AM, Oliver Hartkopp wrote:
> > Hi Rong,
> >
> > On 22.03.21 09:52, Rong Chen wrote:
> >
> >> On 3/21/21 10:19 PM, Oliver Hartkopp wrote:
> >>> Two reminders in two days? ;-)
> >>>
> >>> Did you check my answer here?
> >>> https://lore.kernel.org/lkml/afffeb73-ba4c-ca2c-75d0-9e7899e5c...@hartkopp.net/
> >>>
> >>>
> >>> And did you try the partly revert?
> >>
> >> Hi Oliver,
> >>
> >> Sorry for the delay, we tried the revert patch and the problem still
> >> exists,
> >> we also found that commit c7b74967 changed the error message which
> >> triggered
> >> the report.
> >>
> >> The problem is that offsetof(struct can_frame, data) !=
> >> offsetof(struct canfd_frame, data)
> >> the following struct layout shows that the offset has been changed by
> >> union:
> >>
> >> struct can_frame {
> >> canid_tcan_id; /* 0 4 */
> >> union {
> >> __u8 len; /* 4 1 */
> >> __u8 can_dlc; /* 4 1 */
> >> }; /* 4 4 */
> >
> > Ugh! Why did the compiler extend the space for the union to 4 bytes?!?
Just a random idea but maybe the added padding is due to some
kind of odd intrication with the __attribute__((__aligned__(8)))
just below? Does this reproduce if we remove the
__attribute__((__aligned__(8)))?
(I am not saying that we should permanently remove it, this is
only a suggestion for troubleshooting).
> >> __u8 __pad;/* 8 1 */
> >> __u8 __res0; /* 9 1 */
> >> __u8 len8_dlc; /* 10 1 */
> >>
> >> /* XXX 5 bytes hole, try to pack */
> >>
> >> __u8 data[8]
> >> __attribute__((__aligned__(8))); /*16 8 */
> >>
> >> /* size: 24, cachelines: 1, members: 6 */
> >> /* sum members: 19, holes: 1, sum holes: 5 */
> >> /* forced alignments: 1, forced holes: 1, sum forced holes:
> >> 5 */
> >> /* last cacheline: 24 bytes */
> >> } __attribute__((__aligned__(8)));
> >>
> >> struct canfd_frame {
> >> canid_tcan_id; /* 0 4 */
> >> __u8 len; /* 4 1 */
> >> __u8 flags;/* 5 1 */
> >> __u8 __res0; /* 6 1 */
> >> __u8 __res1; /* 7 1 */
> >> __u8 data[64]
> >> __attribute__((__aligned__(8))); /* 864 */
> >>
> >> /* size: 72, cachelines: 2, members: 6 */
> >> /* forced alignments: 1 */
> >> /* last cacheline: 8 bytes */
> >> } __attribute__((__aligned__(8)))
> >>
> >>
> >> and I tried to add "__attribute__((packed))" to the union, the issue
> >> is gone:
> >>
> >> diff --git a/include/uapi/linux/can.h b/include/uapi/linux/can.h
> >> index f75238ac6dce..9842bb55ffd9 100644
> >> --- a/include/uapi/linux/can.h
> >> +++ b/include/uapi/linux/can.h
> >> @@ -113,7 +113,7 @@ struct can_frame {
> >> */
> >> __u8 len;
> >> __u8 can_dlc; /* deprecated */
> >> - };
> >> + } __attribute__((packed));
> >> __u8 __pad; /* padding */
> >> __u8 __res0; /* reserved / padding */
> >> __u8 len8_dlc; /* optional DLC for 8 byte payload length (9
> >> .. 15) */
> >
> > This is pretty strange!
> >
> > pahole on my x86_64 machine shows the correct data structure layout:
> >
> > struct can_frame {
> > canid_tcan_id; /* 0 4 */
> > union {
> > __u8 len; /* 4 1 */
> > __u8 can_dlc; /* 4 1 */
> > }; /* 4 1 */
> > __u8 __pad;/* 5 1 */
> > __u8 __res0; /* 6 1 */
> > __u8 len8_dlc; /* 7 1 */
> > __u8 data[8]
> > __attribute__((__aligned__(8))); /* 8 8 */
> >
> > /* size: 16, cachelines: 1, members: 6 */
> > /* forced alignments: 1 */
> > /* last cacheline: 16 bytes */
> > } __attribute__((__aligned__(8)));
> >
> > Target: x86_64-linux-gnu
> > gcc version 10.2.1 20210110 (Debian 10.2.1-6)
> > Linux 5.12.0-rc3-00070-g8b12a62a4e3e x86_64 GNU/Linux
> >
> > So it looks like your compiler does not behave correctly - and I
> > wonder if it would be the correct approach to add the __packed()
> > attribute or better fix/change the
Re: [PATCH] hwmon: (ftsteutates): Rudimentary typo fixes
On 3/22/21 9:34 PM, Bhaskar Chowdhury wrote:
>
> s/Temprature/Temperature/
> s/revsion/revision/
>
> Signed-off-by: Bhaskar Chowdhury
Acked-by: Randy Dunlap
> ---
> drivers/hwmon/ftsteutates.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hwmon/ftsteutates.c b/drivers/hwmon/ftsteutates.c
> index ef88a156efc2..ceffc76a0c51 100644
> --- a/drivers/hwmon/ftsteutates.c
> +++ b/drivers/hwmon/ftsteutates.c
> @@ -509,7 +509,7 @@ fan_alarm_store(struct device *dev, struct
> device_attribute *devattr,
> /* SysFS structs */
>
> /*/
>
> -/* Temprature sensors */
> +/* Temperature sensors */
> static SENSOR_DEVICE_ATTR_RO(temp1_input, temp_value, 0);
> static SENSOR_DEVICE_ATTR_RO(temp2_input, temp_value, 1);
> static SENSOR_DEVICE_ATTR_RO(temp3_input, temp_value, 2);
> @@ -713,7 +713,7 @@ static int fts_detect(struct i2c_client *client,
> {
> int val;
>
> - /* detection works with revsion greater or equal to 0x2b */
> + /* detection works with revision greater or equal to 0x2b */
> val = i2c_smbus_read_byte_data(client, FTS_DEVICE_REVISION_REG);
> if (val < 0x2b)
> return -ENODEV;
> --
--
~Randy
Re: [PATCH] tools: testing: Remove duplicate include of sched.h
Le 23/03/2021 à 04:34, Wan Jiabing a écrit : sched.h has been included at line 33. So we remove the duplicate one at line 36. Can you please send a single patch for all files in tools/testing/selftests/powerpc/ Thanks Christophe Signed-off-by: Wan Jiabing --- tools/testing/selftests/powerpc/mm/tlbie_test.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/testing/selftests/powerpc/mm/tlbie_test.c b/tools/testing/selftests/powerpc/mm/tlbie_test.c index f85a0938ab25..48344a74b212 100644 --- a/tools/testing/selftests/powerpc/mm/tlbie_test.c +++ b/tools/testing/selftests/powerpc/mm/tlbie_test.c @@ -33,7 +33,6 @@ #include #include #include -#include #include #include #include
linux-next: build warning after merge of the sound-asoc tree
Hi all,
After merging the sound-asoc tree, today's linux-next build (powerpc
allyesconfig) produced this warning:
sound/soc/amd/acp-da7219-max98357a.c:684:28: warning: 'cz_rt5682_card' defined
but not used [-Wunused-variable]
684 | static struct snd_soc_card cz_rt5682_card = {
|^~
sound/soc/amd/acp-da7219-max98357a.c:671:28: warning: 'cz_card' defined but not
used [-Wunused-variable]
671 | static struct snd_soc_card cz_card = {
|^~~
Introduced by commit
7e71b48f9e27 ("ASoC: amd: Add support for RT5682 codec in machine driver")
--
Cheers,
Stephen Rothwell
pgpKrzfX_1vvo.pgp
Description: OpenPGP digital signature
Re: [PATCH] octeontx2-af: cn10k: Few mundane typos fixed
On 3/22/21 9:28 PM, Bhaskar Chowdhury wrote:
>
> s/preceeds/precedes/ .two different places
> s/rsponse/response/
> s/cetain/certain/
> s/precison/precision/
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> drivers/net/ethernet/marvell/octeontx2/af/mbox.h | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
> b/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
> index ea456099b33c..14a184c3f6a4 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
> @@ -277,7 +277,7 @@ struct msg_req {
> struct mbox_msghdr hdr;
> };
>
> -/* Generic rsponse msg used a ack or response for those mbox
> +/* Generic response msg used a ack or response for those mbox> * messages
> which doesn't have a specific rsp msg format.
> */
Nak, negative. ETOOMANYERRORS.
How about:
/* Generic response msg used an ack or response for those mbox
* messages which don't have a specific rsp msg format.
*/
The other changes look good.
--
~Randy
Re: [PATCH] arch: powerpc: Remove duplicate include of interrupt.h
Le 23/03/2021 à 03:41, Wan Jiabing a écrit : asm/interrupt.h has been included at line 12. According to alphabetic order,we remove the duplicate one at line 10. Could you please cook a single patch for all files in arch/powerpc/ Thanks Christophe Signed-off-by: Wan Jiabing --- arch/powerpc/kernel/interrupt.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/powerpc/kernel/interrupt.c b/arch/powerpc/kernel/interrupt.c index c475a229a42a..11d456896772 100644 --- a/arch/powerpc/kernel/interrupt.c +++ b/arch/powerpc/kernel/interrupt.c @@ -7,7 +7,6 @@ #include #include #include -#include #include #include #include
[syzbot] WARNING in io_sq_thread_park
Hello, syzbot found the following issue on: HEAD commit:84196390 Merge tag 'selinux-pr-20210322' of git://git.kern.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=152a6ad6d0 kernel config: https://syzkaller.appspot.com/x/.config?x=5adab0bdee099d7a dashboard link: https://syzkaller.appspot.com/bug?extid=e3a3f84f5cecf61f0583 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+e3a3f84f5cecf61f0...@syzkaller.appspotmail.com [ cut here ] WARNING: CPU: 1 PID: 27907 at fs/io_uring.c:7147 io_sq_thread_park+0xb5/0xd0 fs/io_uring.c:7147 Modules linked in: CPU: 1 PID: 27907 Comm: iou-sqp-27905 Not tainted 5.12.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:io_sq_thread_park+0xb5/0xd0 fs/io_uring.c:7147 Code: 3c 02 00 75 29 48 8b ab a8 00 00 00 48 85 ed 74 0d e8 df a3 99 ff 48 89 ef e8 f7 49 75 ff 5b 5d e9 d0 a3 99 ff e8 cb a3 99 ff <0f> 0b eb 85 48 89 ef e8 bf 36 dd ff eb cd 48 89 ef e8 b5 36 dd ff RSP: 0018:c90001bff9e8 EFLAGS: 00010293 RAX: RBX: 88802489a000 RCX: RDX: 88808e7e RSI: 81da4a65 RDI: 88802489a000 RBP: 88802489a0a8 R08: 0001 R09: 88806a7420c7 R10: ed100d4e8418 R11: R12: 88806a742590 R13: 88806a742458 R14: 19200037ff42 R15: 88806a7424b8 FS: 7f63505a8700() GS:8880b9c0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 00540198 CR3: 24531000 CR4: 00350ef0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0111062a Call Trace: io_ring_ctx_wait_and_kill+0x214/0x700 fs/io_uring.c:8619 io_uring_release+0x3e/0x50 fs/io_uring.c:8646 __fput+0x288/0x920 fs/file_table.c:280 task_work_run+0xdd/0x1a0 kernel/task_work.c:140 io_run_task_work fs/io_uring.c:2238 [inline] io_run_task_work fs/io_uring.c:2228 [inline] io_uring_try_cancel_requests+0x8ec/0xc60 fs/io_uring.c:8770 io_uring_cancel_sqpoll+0x1cf/0x290 fs/io_uring.c:8974 io_sqpoll_cancel_cb+0x87/0xb0 fs/io_uring.c:8907 io_run_task_work_head+0x58/0xb0 fs/io_uring.c:1961 io_sq_thread+0x3e2/0x18d0 fs/io_uring.c:6763 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Re: [PATCH] perf tools: Trivial spelling fixes
On 3/22/21 9:46 PM, Bhaskar Chowdhury wrote:
>
> s/succeded/succeeded/ five different places
> s/revsions/revisions/
>
> Signed-off-by: Bhaskar Chowdhury
Acked-by: Randy Dunlap
> ---
> tools/perf/util/header.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
> index 20effdff76ce..97a0eeb6d2ab 100644
> --- a/tools/perf/util/header.c
> +++ b/tools/perf/util/header.c
> @@ -127,7 +127,7 @@ static int __do_write_buf(struct feat_fd *ff, const void
> *buf, size_t size)
> return 0;
> }
>
> -/* Return: 0 if succeded, -ERR if failed. */
> +/* Return: 0 if succeeded, -ERR if failed. */
> int do_write(struct feat_fd *ff, const void *buf, size_t size)
> {
> if (!ff->buf)
> @@ -135,7 +135,7 @@ int do_write(struct feat_fd *ff, const void *buf, size_t
> size)
> return __do_write_buf(ff, buf, size);
> }
>
> -/* Return: 0 if succeded, -ERR if failed. */
> +/* Return: 0 if succeeded, -ERR if failed. */
> static int do_write_bitmap(struct feat_fd *ff, unsigned long *set, u64 size)
> {
> u64 *p = (u64 *) set;
> @@ -154,7 +154,7 @@ static int do_write_bitmap(struct feat_fd *ff, unsigned
> long *set, u64 size)
> return 0;
> }
>
> -/* Return: 0 if succeded, -ERR if failed. */
> +/* Return: 0 if succeeded, -ERR if failed. */
> int write_padded(struct feat_fd *ff, const void *bf,
>size_t count, size_t count_aligned)
> {
> @@ -170,7 +170,7 @@ int write_padded(struct feat_fd *ff, const void *bf,
> #define string_size(str) \
> (PERF_ALIGN((strlen(str) + 1), NAME_ALIGN) + sizeof(u32))
>
> -/* Return: 0 if succeded, -ERR if failed. */
> +/* Return: 0 if succeeded, -ERR if failed. */
> static int do_write_string(struct feat_fd *ff, const char *str)
> {
> u32 len, olen;
> @@ -266,7 +266,7 @@ static char *do_read_string(struct feat_fd *ff)
> return NULL;
> }
>
> -/* Return: 0 if succeded, -ERR if failed. */
> +/* Return: 0 if succeeded, -ERR if failed. */
> static int do_read_bitmap(struct feat_fd *ff, unsigned long **pset, u64
> *psize)
> {
> unsigned long *set;
> @@ -3485,7 +3485,7 @@ static const size_t attr_pipe_abi_sizes[] = {
> * between host recording the samples, and host parsing the samples is the
> * same. This is not always the case given that the pipe output may always be
> * redirected into a file and analyzed on a different machine with possibly a
> - * different endianness and perf_event ABI revsions in the perf tool itself.
> + * different endianness and perf_event ABI revisions in the perf tool itself.
> */
> static int try_all_pipe_abis(uint64_t hdr_sz, struct perf_header *ph)
> {
> --
--
~Randy
RE: Re: [PATCH v31 2/4] scsi: ufs: L2P map management for HPB read
>On 2021-03-23 12:22, Can Guo wrote:
>> On 2021-03-22 17:11, Bean Huo wrote:
>>> On Mon, 2021-03-22 at 15:54 +0900, Daejun Park wrote:
+ switch (rsp_field->hpb_op) {
+ case HPB_RSP_REQ_REGION_UPDATE:
+ if (data_seg_len != DEV_DATA_SEG_LEN)
+ dev_warn(>sdev_ufs_lu->sdev_dev,
+"%s: data seg length is not
same.\n",
+__func__);
+ ufshpb_rsp_req_region_update(hpb, rsp_field);
+ break;
+ case HPB_RSP_DEV_RESET:
+ dev_warn(>sdev_ufs_lu->sdev_dev,
+"UFS device lost HPB information during
PM.\n");
+ break;
>>>
>>> Hi Deajun,
>>> This series looks good to me. Just here I have one question. You
>>> didn't
>>> handle HPB_RSP_DEV_RESET, just a warning. Based on your SS UFS, how
>>> to
>>> handle HPB_RSP_DEV_RESET from the host side? Do you think we shoud
>>> reset host side HPB entry as well or what else?
>>>
>>>
>>> Bean
>>
>> Same question here - I am still collecting feedbacks from flash vendors
>> about
>> what is recommanded host behavior on reception of HPB Op code 0x2,
>> since it
>> is not cleared defined in HPB2.0 specs.
>>
>> Can Guo.
>
>I think the question should be asked in the HPB2.0 patch, since in
>HPB1.0 device
>control mode, a HPB reset in device side does not impact anything in
>host side -
>host is not writing back any HPB entries to device anyways and HPB Read
>cmd with
>invalid HPB entries shall be treated as normal Read(10) cmd without any
>problems.
Yes, UFS device will process read command even the HPB entries are valid or
not. So it is warning about read performance drop by dev reset.
Thanks,
Daejun
>Please correct me if I am wrong.
>Thanks,
>Can Guo.
>
>
>
Re: [PATCH] rcu: Fix various typos in comments
On Tue, Mar 23, 2021 at 08:26:14AM +0530, Bhaskar Chowdhury wrote:
> On 00:02 Tue 23 Mar 2021, Ingo Molnar wrote:
> >
> > Hi Paul,
> >
> > Was working on automation to make it a bit more straightforward to fix
> > typos within comments (which we tend to reintroduce during
> > development), and here are the ones it found in the RCU code.
> >
> > Thanks,
> >
> > Ingo
> >
> > =>
> > From: Ingo Molnar
> > Date: Mon, 22 Mar 2021 23:57:26 +0100
> > Subject: [PATCH] rcu: Fix various typos in comments
> >
> > Fix ~12 single-word typos in RCU code comments.
> >
> > Signed-off-by: Ingo Molnar
> > Cc: Paul E. McKenney
> > Cc: linux-kernel@vger.kernel.org
> > ---
> > kernel/rcu/srcutree.c | 4 ++--
> > kernel/rcu/sync.c | 2 +-
> > kernel/rcu/tasks.h | 8
> > kernel/rcu/tree.c | 4 ++--
> > kernel/rcu/tree.h | 2 +-
> > kernel/rcu/tree_plugin.h| 2 +-
> > tools/testing/selftests/rcutorture/formal/srcu-cbmc/src/locks.h | 2 +-
> > 7 files changed, 12 insertions(+), 12 deletions(-)
> >
> > diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
> > index e26547b34ad3..036ff5499ad5 100644
> > --- a/kernel/rcu/srcutree.c
> > +++ b/kernel/rcu/srcutree.c
> > @@ -777,9 +777,9 @@ static bool srcu_might_be_idle(struct srcu_struct *ssp)
> > spin_unlock_irqrestore_rcu_node(sdp, flags);
> >
> > /*
> > -* No local callbacks, so probabalistically probe global state.
> > +* No local callbacks, so probabilistically probe global state.
> > * Exact information would require acquiring locks, which would
> > -* kill scalability, hence the probabalistic nature of the probe.
> > +* kill scalability, hence the probabilistic nature of the probe.
> > */
> >
> > /* First, see if enough time has passed since the last GP. */
> > diff --git a/kernel/rcu/sync.c b/kernel/rcu/sync.c
> > index d4558ab7a07d..3eeb871cf0de 100644
> > --- a/kernel/rcu/sync.c
> > +++ b/kernel/rcu/sync.c
> > @@ -94,7 +94,7 @@ static void rcu_sync_func(struct rcu_head *rhp)
> > rcu_sync_call(rsp);
> > } else {
> > /*
> > -* We're at least a GP after the last rcu_sync_exit(); eveybody
> > +* We're at least a GP after the last rcu_sync_exit(); everybody
> > * will now have observed the write side critical section.
> > * Let 'em rip!.
> > */
> > diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h
> > index af7c19439f4e..ac3c362e08a3 100644
> > --- a/kernel/rcu/tasks.h
> > +++ b/kernel/rcu/tasks.h
> > @@ -23,7 +23,7 @@ typedef void (*postgp_func_t)(struct rcu_tasks *rtp);
> > * Definition for a Tasks-RCU-like mechanism.
> > * @cbs_head: Head of callback list.
> > * @cbs_tail: Tail pointer for callback list.
> > - * @cbs_wq: Wait queue allowning new callback to get kthread's attention.
> > + * @cbs_wq: Wait queue allowing new callback to get kthread's attention.
> > * @cbs_lock: Lock protecting callback list.
> > * @kthread_ptr: This flavor's grace-period/callback-invocation kthread.
> > * @gp_func: This flavor's grace-period-wait function.
> > @@ -504,7 +504,7 @@ DEFINE_RCU_TASKS(rcu_tasks, rcu_tasks_wait_gp,
> > call_rcu_tasks, "RCU Tasks");
> > * or transition to usermode execution. As such, there are no read-side
> > * primitives analogous to rcu_read_lock() and rcu_read_unlock() because
> > * this primitive is intended to determine that all tasks have passed
> > - * through a safe state, not so much for data-strcuture synchronization.
> > + * through a safe state, not so much for data-structure synchronization.
> > *
> > * See the description of call_rcu() for more detailed information on
> > * memory ordering guarantees.
> > @@ -637,7 +637,7 @@ DEFINE_RCU_TASKS(rcu_tasks_rude,
> > rcu_tasks_rude_wait_gp, call_rcu_tasks_rude,
> > * there are no read-side primitives analogous to rcu_read_lock() and
> > * rcu_read_unlock() because this primitive is intended to determine
> > * that all tasks have passed through a safe state, not so much for
> > - * data-strcuture synchronization.
> > + * data-structure synchronization.
> > *
>
> The "hyphen" in the middle of the word "data structure" is required or
> keeping by
> convention or has some significance?
Yes, this is one of many peculiarities of English, and an optional one
at that. English is not a block-structured language, so grouping can
be ambiguous. Is is "(data structure) synchronization" or is it instead
"data (structure synchronization)"? The default is the latter, and
the hyphen indicates the former. In this case, the former is intended,
hence the hyphen.
> > * See the description of call_rcu() for more detailed information on
> > * memory ordering guarantees.
> > @@ -1127,7
[PATCH] HID: quirks: Set INCREMENT_USAGE_ON_DUPLICATE for Saitek X65
The Saitek X65 joystick has a pair of axes that were used as mouse
pointer controls by the Windows driver. The corresponding usage page is
the Game Controls page, which is not recognized by the generic HID
driver, and therefore, both axes get mapped to ABS_MISC. The quirk makes
the second axis get mapped to ABS_MISC+1, and therefore made available
separately.
Signed-off-by: Nirenjan Krishnan
---
drivers/hid/hid-ids.h| 1 +
drivers/hid/hid-quirks.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index e42aaae..413a06a0 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -1039,6 +1039,7 @@
#define USB_DEVICE_ID_SAITEK_X52 0x075c
#define USB_DEVICE_ID_SAITEK_X52_2 0x0255
#define USB_DEVICE_ID_SAITEK_X52_PRO 0x0762
+#define USB_DEVICE_ID_SAITEK_X65 0x0b6a
#define USB_VENDOR_ID_SAMSUNG 0x0419
#define USB_DEVICE_ID_SAMSUNG_IR_REMOTE0x0001
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 1a9daf0..df68dd7 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -158,6 +158,7 @@ static const struct hid_device_id hid_quirks[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_X52),
HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE },
{ HID_USB_DEVICE(USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_X52_2),
HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE },
{ HID_USB_DEVICE(USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_X52_PRO),
HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_X65),
HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE },
{ HID_USB_DEVICE(USB_VENDOR_ID_SEMICO,
USB_DEVICE_ID_SEMICO_USB_KEYKOARD2), HID_QUIRK_NO_INIT_REPORTS },
{ HID_USB_DEVICE(USB_VENDOR_ID_SEMICO,
USB_DEVICE_ID_SEMICO_USB_KEYKOARD), HID_QUIRK_NO_INIT_REPORTS },
{ HID_USB_DEVICE(USB_VENDOR_ID_SENNHEISER,
USB_DEVICE_ID_SENNHEISER_BTD500USB), HID_QUIRK_NOGET },
--
2.7.4
Re: [PATCH] rcu: Fix various typos in comments
On Mon, Mar 22, 2021 at 07:55:05PM -0700, Randy Dunlap wrote:
> On 3/22/21 4:02 PM, Ingo Molnar wrote:
> >
> > Hi Paul,
> >
> > Was working on automation to make it a bit more straightforward to fix
> > typos within comments (which we tend to reintroduce during
> > development), and here are the ones it found in the RCU code.
> >
> > Thanks,
> >
> > Ingo
> >
> > =>
> > From: Ingo Molnar
> > Date: Mon, 22 Mar 2021 23:57:26 +0100
> > Subject: [PATCH] rcu: Fix various typos in comments
> >
> > Fix ~12 single-word typos in RCU code comments.
> >
> > Signed-off-by: Ingo Molnar
> > Cc: Paul E. McKenney
> > Cc: linux-kernel@vger.kernel.org
> > ---
> > kernel/rcu/srcutree.c | 4 ++--
> > kernel/rcu/sync.c | 2 +-
> > kernel/rcu/tasks.h | 8
> >
> > kernel/rcu/tree.c | 4 ++--
> > kernel/rcu/tree.h | 2 +-
> > kernel/rcu/tree_plugin.h| 2 +-
> > tools/testing/selftests/rcutorture/formal/srcu-cbmc/src/locks.h | 2 +-
> > 7 files changed, 12 insertions(+), 12 deletions(-)
>
> > diff --git a/kernel/rcu/sync.c b/kernel/rcu/sync.c
> > index d4558ab7a07d..3eeb871cf0de 100644
> > --- a/kernel/rcu/sync.c
> > +++ b/kernel/rcu/sync.c
> > @@ -94,7 +94,7 @@ static void rcu_sync_func(struct rcu_head *rhp)
> > rcu_sync_call(rsp);
> > } else {
> > /*
> > -* We're at least a GP after the last rcu_sync_exit(); eveybody
> > +* We're at least a GP after the last rcu_sync_exit(); everybody
> > * will now have observed the write side critical section.
> > * Let 'em rip!.
>
> Drop the '.'.
>
> > */
> Otherwise LGTM. Thanks.
>
> Reviewed-by: Randy Dunlap
Applied, dropping the "." and adding the Reviewed-by.
Thank you both!
Thanx, Paul
Re: [net-next PATCH v7 04/16] of: mdio: Refactor of_phy_find_device()
On Fri, Mar 19, 2021 at 11:21:15AM +, Daniel Thompson wrote: > On Wed, Mar 17, 2021 at 02:15:20PM +0530, Calvin Johnson wrote: > > Hi Daniel, > > > > On Tue, Mar 16, 2021 at 07:17:19PM +, Daniel Thompson wrote: > > > On Thu, Mar 11, 2021 at 11:49:59AM +0530, Calvin Johnson wrote: > > > > Refactor of_phy_find_device() to use fwnode_phy_find_device(). > > > > > > > > Signed-off-by: Calvin Johnson > > > > > > This patch series is provoking depmod dependency cycles for me and > > > it bisected down to this patch (although I think later patches in > > > the series add further cycles). > > > > > > The problems emerge when running modules_install either directly or > > > indirectly via packaging rules such as bindeb-pkg. > > > > > > ~~~ > > > make -j16 INSTALL_MOD_PATH=$PWD/modules modules_install > > > ... > > > INSTALL sound/usb/misc/snd-ua101.ko > > > INSTALL sound/usb/snd-usb-audio.ko > > > INSTALL sound/usb/snd-usbmidi-lib.ko > > > INSTALL sound/xen/snd_xen_front.ko > > > DEPMOD 5.12.0-rc3-9-g1fda33bf463d > > > depmod: ERROR: Cycle detected: fwnode_mdio -> of_mdio -> fwnode_mdio > > > depmod: ERROR: Found 2 modules in dependency cycles! > > > ~~~ > > > > > > Kconfig can be found here: > > > https://gist.github.com/daniel-thompson/6a7d224f3d3950ffa3f63f979b636474 > > > > > > This Kconfig file is for a highly modular kernel derived from the Debian > > > 5.10 arm64 kernel config. I was not able to reproduce using the defconfig > > > kernel for arm64. > > > > > Thanks for catching this. I'm able to reproduce the issue and will fix it. > > > > By the way, is there any integration tool/mechanism out there to which I can > > submit the patch series and build for various possible configs like these? > > Not sure which autotester would be most likely to pick this up. > > This issue is slightly unusual because it broke the install rather then > the build... and lots of people (including me) primarily run build > tests ;-) . > > Anyhow, I guess the best way to pick up module problems like this is > going to be an `allmodconfig` build followed up with `rm -rf modtest; > make modules_install INSTALL_MOD_PATH=$PWD/modtest`. Thanks Daniel for the info. To resolve this issue, I need to add more fwnode MDIO functions. I'm working on these. Meanwhile, will separately send out two patches that got Reviewed-by tag. Regards Calvin
Re: [PATCH v7 3/3] arm64: dts: ti: k3-j7200: Add support for higher speed modes and update delay select values for MMCSD subsystems
Hi Nishanth,
On 22/03/21 9:05 pm, Nishanth Menon wrote:
> On 18:42-20210322, Aswath Govindraju wrote:
>> The following speed modes are now supported in J7200 SoC,
>> - HS200 and HS400 modes at 1.8 V card voltage, in MMCSD0 subsystem [1].
>> - UHS-I speed modes in MMCSD1 subsystem [1].
>>
>> Add support for UHS-I modes by adding voltage regulator device tree nodes
>> and corresponding pinmux details, to power cycle and voltage switch cards.
>> Set respective tags in sdhci0 and remove no-1-8-v tag from sdhci1
>> device tree nodes.
>>
>> Also update the delay values for various speed modes supported, based on
>> the revised january 2021 J7200 datasheet[2].
>>
>> [1] - section 12.3.6.1.1 MMCSD Features, in
>> https://www.ti.com/lit/ug/spruiu1a/spruiu1a.pdf,
>> (SPRUIU1A – JULY 2020 – REVISED JANUARY 2021)
>>
>> [2] - https://www.ti.com/lit/ds/symlink/dra821u.pdf,
>> (SPRSP57B – APRIL 2020 – REVISED JANUARY 2021)
>>
>> Signed-off-by: Aswath Govindraju
>> ---
>> .../dts/ti/k3-j7200-common-proc-board.dts | 42 +++
>> arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 14 ++-
>> 2 files changed, 54 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
>> b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
>> index b493f939b09a..de8c06bdc825 100644
>> --- a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
>> +++ b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
>> @@ -16,6 +16,29 @@
>> stdout-path = "serial2:115200n8";
>> bootargs = "console=ttyS2,115200n8
>> earlycon=ns16550a,mmio32,0x0280";
>> };
>> +
>> +vdd_mmc1: fixedregulator-sd {
>> +compatible = "regulator-fixed";
>> +regulator-name = "vdd_mmc1";
>> +regulator-min-microvolt = <330>;
>> +regulator-max-microvolt = <330>;
>> +regulator-boot-on;
>> +enable-active-high;
>> +gpios = < 2 GPIO_ACTIVE_HIGH>;
>
> is that gpio ?
Yes, that is correct. I'll correct it in the respin
> I'd encourage to use vin-supply as well.
Will add this in respin.
>
>> +};
>> +
>> +vdd_sd_dv: gpio-regulator-vdd-sd-dv {
> What does this drive? TLV71033 ?
Yes, this node models the TLV71033 voltage regulator that switches the
MMC IO signal voltage level between 3.3V and 1.8V.
>> +compatible = "regulator-gpio";
>> +regulator-name = "vdd_sd_dv";
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_sd_dv_pins_default>;
>> +regulator-min-microvolt = <180>;
>> +regulator-max-microvolt = <330>;
>> +regulator-boot-on;
>
> normally, I'd encourage to use vin-supply as well.
Will add this in the respin
>
>> +gpios = <_gpio0 55 GPIO_ACTIVE_HIGH>;
>> +states = <180 0x0
>> + 330 0x1>;
> states = <180 0x0>,
> <330 0x1>;
>
Will make this change in the respin.
> Can you look at j721e as reference?
>
Will make changes accordingly.
>> +};
>> };
>>
>
> Kishon,
> can you look closer at this series?
>
I'll wait for kishon's feedback and then post respin of this series.
Thank you for the review.
Regards,
Aswath
Re: GTE - The hardware timestamping engine
On Mon, Mar 22, 2021 at 09:09:50PM -0700, Dipen Patel wrote: > > > On 3/22/21 7:59 PM, Kent Gibson wrote: > > On Mon, Mar 22, 2021 at 06:53:10PM -0700, Dipen Patel wrote: > >> > >> > >> On 3/22/21 5:32 PM, Kent Gibson wrote: > >>> On Mon, Mar 22, 2021 at 01:21:46PM -0700, Dipen Patel wrote: > Hi Linus and Kent, > > > > > [snip] > > > >>> In response to all your comments above... > >>> > >>> Firstly, I'm not suggesting that other kernel modules would use the > >>> cdev lineevents, only that they would use the same mechanism that > >>> gpiolib-cdev would use to timestamp the lineevents for userspace. > >>> > >> Sure, I just wanted to mention the different scenarios and wanted to know > >> how can we fit all those together. Having said that, shouldn't this serve > >> an opportunity to extend the linevent framework to accommodate kernel > >> drivers as a clients? > >> > >> If we can't, then there is a risk of duplicating lineevent mechanism in all > >> of those kernel drivers or at least in GTE framework/infrastructure as far > >> as GPIO related GTE part is concerned. > >> > > > > In-kernel the lineevents are just IRQs so anything needing a "lineevent" > > can request the IRQ directly. Or am I missing something? > > > > In the GPIO context, I meant we can extend line_event_timestamp to kernel > drivers as well in that way, both userspace and kernel drivers requesting > particular GPIO for the hardware timestamp would be managed by same > lineevent_* infrastructure from the gpiolib. Something like lineevent_create > version of the kernel drivers, so if they need hardware timestamp on the > GPIO line, they can request with some flags. In that way, GTE can leverage > linevent* codes from gpiolib to cover its both the GPIO related use cases i.e. > userspace app and kernel drivers. > I still don't see what that gives you that is better than an IRQ and a function to provide the timestamp for that IRQ. What specific features of a lineevent are you after? The gpiolib-cdev code is there to provide a palettable API for userspace, and the bulk of that code is specific to the userspace API. Reusing that code for clients within the kernel is just introducing pointless overhead when they can get what they need more directly. There may be a case for some additional gpiolib/irq helper functions, but I don't see gpiolib-cdev as a good fit for that role. > >>> As to that mechanism, my current thinking is that the approach of > >>> associating GTE event FIFO entries with particular physical IRQ events is > >>> problematic, as keeping the two in sync would be difficult, if not > >>> impossible. > >>> > >>> A more robust approach is to ignore the physical IRQs and instead service > >>> the GTE event FIFO, generating IRQs from those events in software - > >>> essentially a pre-timestamped IRQ. The IRQ framework could provide the > >>> timestamping functionality, equivalent to line_event_timestamp(), for > >>> the IRQ handler/thread and in this case provide the timestamp from the GTE > >>> event. > >>> > >> > >> I have not fully understood above two paragraphs (except about > >> lineevent_event_timestamp related part). > >> > >> I have no idea what it means to "ignore the physical IRQs and service the > >> GTE event FIFO". Just like GPIO clients, there could be IRQ clients which > >> want to monitor certain IRQ line, like ethernet driver wanted to retrieve > >> timestamp for its IRQ line and so on. > >> > > > > I mean that in the IRQ framework, rather than enabling the physical IRQ > > line it would leave that masked and would instead enable the FIFO line to > > service the FIFO, configure the GTE to generate the events for that > > line, and then generate IRQs in response to the FIFO events. > > That way the client requesting the IRQ is guaranteed to only receive an > > IRQ that corresponds to a GTE FIFO event and the timestamp stored in the > > IRQ framework would match. > > > > I do not think we need to do such things, for example, below is > the rough sequence how GTE can notify its clients be it GPIO or IRQ > lines. I believe this will also help understand better ongoing GPIO > discussions. > > 1. Configure GTE FIFO watermark or threshold, lets assume 1, i.e >generate GTE interrupt when FIFO depth is 1. > 2. In the GTE ISR or ISR thread, drain internal FIFO entries > 3. Through GTE driver's internal mapping, identify which IRQ or >GPIO number this entry belongs to. (This is possible as GTE >has predefined bits for each supported signals, for example GTE >supports 40 GPIOs and 352 IRQ lines, and it has multliple GTE instances >which can take care all of them) > 4. GTE driver pushes the event data (in this case it will be timestamp and >direction of the event ie.rising or falling) to the GTE generic framework > 5. GTE framework will store per event data to its per client/event sw FIFO > 6. wake up any sleeping client thread > 7. Points 3 to 6 are happening in GTE ISR
Re: [PATCH v2 01/18] vfs: add miscattr ops
> > +``miscattr_get`` > > I wish this wasn't named "misc" because miscellaneous is vague. > > fileattr_get, perhaps? > > (FWIW I'm not /that/ passionate about starting a naming bikeshed, feel > free to ignore.) > Eventual bikeshedding is hard to avoid in this case... I don't feel strongly against "misc", but I do think the flags and ioctl are already known as "fsx" so it would be more friendly to go with that. If you don't like "fsxflags" because it's not only flags and you think "fsxattr" is too close to "xattr" (FWIW I don't think it is going to be a source of confusion), we can simply go with get_fsx(), similar to get_acl(). It doesn't matter what name we use as long as everyone is clear on what it is. "struct fsx" is not any more or any less clear than "struct statx" and while "fsx" it is a pretty arbitrary name, it is not much less arbitrary than "miscattr". Thanks, Amir.
[PATCH] fuse: Fix a potential double free in virtio_fs_get_tree
In virtio_fs_get_tree, fm is allocated by kzalloc() and
assigned to fsc->s_fs_info by fsc->s_fs_info=fm statement.
If the kzalloc() failed, it will goto err directly, so that
fsc->s_fs_info must be non-NULL and fm will be freed.
But later fm is freed again when virtio_fs_fill_super() fialed.
I think the statement if (fsc->s_fs_info) {kfree(fm);} is
misplaced.
My patch puts this statement in the correct palce to avoid
double free.
Signed-off-by: Lv Yunlong
---
fs/fuse/virtio_fs.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c
index 8868ac31a3c0..727cf436828f 100644
--- a/fs/fuse/virtio_fs.c
+++ b/fs/fuse/virtio_fs.c
@@ -1437,10 +1437,7 @@ static int virtio_fs_get_tree(struct fs_context *fsc)
fsc->s_fs_info = fm;
sb = sget_fc(fsc, virtio_fs_test_super, set_anon_super_fc);
- if (fsc->s_fs_info) {
- fuse_conn_put(fc);
- kfree(fm);
- }
+
if (IS_ERR(sb))
return PTR_ERR(sb);
@@ -1457,6 +1454,11 @@ static int virtio_fs_get_tree(struct fs_context *fsc)
sb->s_flags |= SB_ACTIVE;
}
+ if (fsc->s_fs_info) {
+ fuse_conn_put(fc);
+ kfree(fm);
+ }
+
WARN_ON(fsc->root);
fsc->root = dget(sb->s_root);
return 0;
--
2.25.1
[PATCH] tools: perf: Remove duplicate includes
sys/stat.h has been included at line 23, so remove the duplicate one at line 27. linux/string.h has been included at line 7, so remove the duplicate one at line 9. time.h has been included at line 14, so remove the duplicate one at line 28. Signed-off-by: Wan Jiabing --- tools/perf/builtin-daemon.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/tools/perf/builtin-daemon.c b/tools/perf/builtin-daemon.c index ace8772a4f03..632ecd010a4f 100644 --- a/tools/perf/builtin-daemon.c +++ b/tools/perf/builtin-daemon.c @@ -6,7 +6,6 @@ #include #include #include -#include #include #include #include @@ -24,8 +23,6 @@ #include #include #include -#include -#include #include "builtin.h" #include "perf.h" #include "debug.h" -- 2.25.1
[rcu:lkmm-dev] BUILD SUCCESS 052aaf10b7a5b2023be4623d2293ae51a6978e27
10323 i386 randconfig-a004-20210323 i386 randconfig-a001-20210323 i386 randconfig-a002-20210323 i386 randconfig-a006-20210323 i386 randconfig-a005-20210323 i386 randconfig-a004-20210322 i386 randconfig-a003-20210322 i386 randconfig-a001-20210322 i386 randconfig-a002-20210322 i386 randconfig-a006-20210322 i386 randconfig-a005-20210322 x86_64 randconfig-a012-20210322 x86_64 randconfig-a015-20210322 x86_64 randconfig-a013-20210322 x86_64 randconfig-a014-20210322 x86_64 randconfig-a016-20210322 x86_64 randconfig-a011-20210322 i386 randconfig-a014-20210322 i386 randconfig-a011-20210322 i386 randconfig-a015-20210322 i386 randconfig-a016-20210322 i386 randconfig-a012-20210322 i386 randconfig-a013-20210322 riscvnommu_k210_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kbuiltin x86_64 kexec clang tested configs: x86_64 randconfig-a002-20210322 x86_64 randconfig-a003-20210322 x86_64 randconfig-a001-20210322 x86_64 randconfig-a006-20210322 x86_64 randconfig-a004-20210322 x86_64 randconfig-a005-20210322 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[rcu:lkmm] BUILD SUCCESS 49ab51b01ec6fd837ae3efe2e0cdb41fcf5cf048
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git lkmm branch HEAD: 49ab51b01ec6fd837ae3efe2e0cdb41fcf5cf048 tools/memory-model: Add access-marking documentation elapsed time: 720m configs tested: 129 configs skipped: 3 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 riscvallmodconfig x86_64 allyesconfig i386 allyesconfig riscvallyesconfig arc axs101_defconfig m68k amiga_defconfig powerpc asp8347_defconfig sh sh7710voipgw_defconfig m68k m5208evb_defconfig arc haps_hs_defconfig powerpc katmai_defconfig sh rts7751r2dplus_defconfig mips ip27_defconfig riscvnommu_virt_defconfig arc alldefconfig arc axs103_defconfig powerpc motionpro_defconfig powerpc chrp32_defconfig arm moxart_defconfig arm colibri_pxa270_defconfig arm s3c2410_defconfig arm ixp4xx_defconfig mips ip28_defconfig arm mxs_defconfig riscvalldefconfig shedosk7705_defconfig powerpc mpc5200_defconfig mips pic32mzda_defconfig powerpc ppc64e_defconfig sh ecovec24_defconfig powerpc mpc85xx_cds_defconfig sh defconfig mips decstation_64_defconfig openrisc simple_smp_defconfig powerpc walnut_defconfig mips capcella_defconfig arm am200epdkit_defconfig powerpc wii_defconfig powerpc akebono_defconfig powerpc redwood_defconfig armlart_defconfig arm palmz72_defconfig armmvebu_v7_defconfig sh se7780_defconfig powerpc mpc836x_rdk_defconfig openrisc alldefconfig m68k m5249evb_defconfig mipsmaltaup_defconfig arm omap1_defconfig i386defconfig arm colibri_pxa300_defconfig mips jazz_defconfig powerpc mpc83xx_defconfig powerpcmpc7448_hpc2_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig s390 allmodconfig parisc allyesconfig s390defconfig sparcallyesconfig sparc defconfig i386 tinyconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a003-20210323 i386 randconfig-a004-20210323 i386 randconfig-a001-20210323 i386 randconfig-a002-20210323 i386 randconfig-a006-20210323 i386 randconfig-a005-20210323 i386 randconfig-a004-20210322 i386 randconfig-a003-20210322 i386 randconfig-a001-20210322 i386 randconfig-a002-20210322 i386
Re: [PATCH] cpufreq: intel_pstate: Clean up frequency computations
On Tue, Mar 16, 2021 at 04:52:43PM +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Notice that some computations related to frequency in intel_pstate > can be simplified if (a) intel_pstate_get_hwp_max() updates the > relevant members of struct cpudata by itself and (b) the "turbo > disabled" check is moved from it to its callers, so modify the code > accordingly and while at it rename intel_pstate_get_hwp_max() to > intel_pstate_get_hwp_cap() which better reflects its purpose and > provide a simplified variat of it, __intel_pstate_get_hwp_cap(), > suitable for the initialization path. > > No intentional functional impact. > > Signed-off-by: Rafael J. Wysocki Tested-by: Chen Yu thanks, Chenyu
Re: [PATCH] ACPI: CPPC: Add emtpy stubs of functions for CONFIG_ACPI_CPPC_LIB unset
On Tue, Mar 16, 2021 at 04:54:03PM +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > For convenience, add empty stubs of library functions defined in > cppc_acpi.c for the CONFIG_ACPI_CPPC_LIB unset case. > > Because one of them needs to return CPUFREQ_ETERNAL, include > linux/cpufreq.h into the CPPC library header file and drop the > direct inclusion of it from cppc_acpi.c. > > Signed-off-by: Rafael J. Wysocki Tested-by: Chen Yu thanks, Chenyu
[PATCH] perf tools: Trivial spelling fixes
s/succeded/succeeded/ five different places
s/revsions/revisions/
Signed-off-by: Bhaskar Chowdhury
---
tools/perf/util/header.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 20effdff76ce..97a0eeb6d2ab 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -127,7 +127,7 @@ static int __do_write_buf(struct feat_fd *ff, const void
*buf, size_t size)
return 0;
}
-/* Return: 0 if succeded, -ERR if failed. */
+/* Return: 0 if succeeded, -ERR if failed. */
int do_write(struct feat_fd *ff, const void *buf, size_t size)
{
if (!ff->buf)
@@ -135,7 +135,7 @@ int do_write(struct feat_fd *ff, const void *buf, size_t
size)
return __do_write_buf(ff, buf, size);
}
-/* Return: 0 if succeded, -ERR if failed. */
+/* Return: 0 if succeeded, -ERR if failed. */
static int do_write_bitmap(struct feat_fd *ff, unsigned long *set, u64 size)
{
u64 *p = (u64 *) set;
@@ -154,7 +154,7 @@ static int do_write_bitmap(struct feat_fd *ff, unsigned
long *set, u64 size)
return 0;
}
-/* Return: 0 if succeded, -ERR if failed. */
+/* Return: 0 if succeeded, -ERR if failed. */
int write_padded(struct feat_fd *ff, const void *bf,
size_t count, size_t count_aligned)
{
@@ -170,7 +170,7 @@ int write_padded(struct feat_fd *ff, const void *bf,
#define string_size(str) \
(PERF_ALIGN((strlen(str) + 1), NAME_ALIGN) + sizeof(u32))
-/* Return: 0 if succeded, -ERR if failed. */
+/* Return: 0 if succeeded, -ERR if failed. */
static int do_write_string(struct feat_fd *ff, const char *str)
{
u32 len, olen;
@@ -266,7 +266,7 @@ static char *do_read_string(struct feat_fd *ff)
return NULL;
}
-/* Return: 0 if succeded, -ERR if failed. */
+/* Return: 0 if succeeded, -ERR if failed. */
static int do_read_bitmap(struct feat_fd *ff, unsigned long **pset, u64 *psize)
{
unsigned long *set;
@@ -3485,7 +3485,7 @@ static const size_t attr_pipe_abi_sizes[] = {
* between host recording the samples, and host parsing the samples is the
* same. This is not always the case given that the pipe output may always be
* redirected into a file and analyzed on a different machine with possibly a
- * different endianness and perf_event ABI revsions in the perf tool itself.
+ * different endianness and perf_event ABI revisions in the perf tool itself.
*/
static int try_all_pipe_abis(uint64_t hdr_sz, struct perf_header *ph)
{
--
2.31.0
Re: [PATCH] staging: wimax: Mundane typo fixes
On 21:14 Mon 22 Mar 2021, Randy Dunlap wrote: On 3/22/21 6:06 PM, Bhaskar Chowdhury wrote: s/procesing/processing/ s/comunication/communication/ Signed-off-by: Bhaskar Chowdhury drivers/staging/wimax/ is in the process of being deleted. Yes ...I saw the mail day or two back ...skipped my mind ...anyway we can ignore this. --- drivers/staging/wimax/i2400m/driver.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/wimax/i2400m/driver.c b/drivers/staging/wimax/i2400m/driver.c index f5186458bb3d..162a92682977 100644 --- a/drivers/staging/wimax/i2400m/driver.c +++ b/drivers/staging/wimax/i2400m/driver.c -- ~Randy signature.asc Description: PGP signature
Re: [PATCH] KVM: VMX: Check the corresponding bits according to the intel sdm
On Tue, Mar 23, 2021 at 11:16 AM Jim Mattson wrote: > > On Mon, Mar 22, 2021 at 7:37 PM wrote: > > > > From: Haiwei Li > > > > According to IA-32 SDM Vol.3D "A.1 BASIC VMX INFORMATION", two inspections > > are missing. > > * Bit 31 is always 0. Earlier versions of this manual specified that the > > VMCS revision identifier was a 32-bit field in bits 31:0 of this MSR. For > > all processors produced prior to this change, bit 31 of this MSR was read > > as 0. > > For all *Intel* processors produced prior to this change, bit 31 of > this MSR may have been 0. However, a conforming hypervisor may have > selected a full 32-bit VMCS revision identifier with the high bit set > for nested VMX. Furthermore, there are other vendors, such as VIA, > which have implemented the VMX extensions, and they, too, may have > selected a full 32-bit VMCS revision identifier with the high bit set. > Intel should know better than to change the documentation after the > horse is out of the barn. Got it, thanks. > > What, exactly, is the value you are adding with this check? I did this just to match the sdm. -- Haiwei Li
[PATCH] brcmfmac: A typo fix
s/revsion/revision/
Signed-off-by: Bhaskar Chowdhury
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.h
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.h
index ee273e3bb101..e000ef78928c 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.h
@@ -28,7 +28,7 @@ struct brcmf_usbdev {
int ntxq, nrxq, rxsize;
u32 bus_mtu;
int devid;
- int chiprev; /* chip revsion number */
+ int chiprev; /* chip revision number */
};
/* IO Request Block (IRB) */
--
2.31.0
[PATCH] hwmon: (ftsteutates): Rudimentary typo fixes
s/Temprature/Temperature/
s/revsion/revision/
Signed-off-by: Bhaskar Chowdhury
---
drivers/hwmon/ftsteutates.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hwmon/ftsteutates.c b/drivers/hwmon/ftsteutates.c
index ef88a156efc2..ceffc76a0c51 100644
--- a/drivers/hwmon/ftsteutates.c
+++ b/drivers/hwmon/ftsteutates.c
@@ -509,7 +509,7 @@ fan_alarm_store(struct device *dev, struct device_attribute
*devattr,
/* SysFS structs*/
/*/
-/* Temprature sensors */
+/* Temperature sensors */
static SENSOR_DEVICE_ATTR_RO(temp1_input, temp_value, 0);
static SENSOR_DEVICE_ATTR_RO(temp2_input, temp_value, 1);
static SENSOR_DEVICE_ATTR_RO(temp3_input, temp_value, 2);
@@ -713,7 +713,7 @@ static int fts_detect(struct i2c_client *client,
{
int val;
- /* detection works with revsion greater or equal to 0x2b */
+ /* detection works with revision greater or equal to 0x2b */
val = i2c_smbus_read_byte_data(client, FTS_DEVICE_REVISION_REG);
if (val < 0x2b)
return -ENODEV;
--
2.31.0
[PATCH 5/6] i2c: mpc: use device managed APIs
Use device managed functions an clean up error handling.
Signed-off-by: Chris Packham
---
drivers/i2c/busses/i2c-mpc.c | 46 ++--
1 file changed, 18 insertions(+), 28 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 5b746a898e8e..46cdb36e2f9b 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -654,7 +654,6 @@ static int fsl_i2c_probe(struct platform_device *op)
u32 clock = MPC_I2C_CLOCK_LEGACY;
int result = 0;
int plen;
- struct resource res;
struct clk *clk;
int err;
@@ -662,7 +661,7 @@ static int fsl_i2c_probe(struct platform_device *op)
if (!match)
return -EINVAL;
- i2c = kzalloc(sizeof(*i2c), GFP_KERNEL);
+ i2c = devm_kzalloc(>dev, sizeof(*i2c), GFP_KERNEL);
if (!i2c)
return -ENOMEM;
@@ -670,24 +669,21 @@ static int fsl_i2c_probe(struct platform_device *op)
init_waitqueue_head(>queue);
- i2c->base = of_iomap(op->dev.of_node, 0);
- if (!i2c->base) {
+ i2c->base = devm_platform_ioremap_resource(op, 0);
+ if (IS_ERR(i2c->base)) {
dev_err(i2c->dev, "failed to map controller\n");
- result = -ENOMEM;
- goto fail_map;
+ return PTR_ERR(i2c->base);
}
- i2c->irq = irq_of_parse_and_map(op->dev.of_node, 0);
- if (i2c->irq < 0) {
- result = i2c->irq;
- goto fail_map;
- }
+ i2c->irq = platform_get_irq(op, 0);
+ if (i2c->irq < 0)
+ return i2c->irq;
- result = request_irq(i2c->irq, mpc_i2c_isr,
+ result = devm_request_irq(>dev, i2c->irq, mpc_i2c_isr,
IRQF_SHARED, "i2c-mpc", i2c);
if (result < 0) {
dev_err(i2c->dev, "failed to attach interrupt\n");
- goto fail_request;
+ return result;
}
/*
@@ -699,7 +695,7 @@ static int fsl_i2c_probe(struct platform_device *op)
err = clk_prepare_enable(clk);
if (err) {
dev_err(>dev, "failed to enable clock\n");
- goto fail_request;
+ return err;
} else {
i2c->clk_per = clk;
}
@@ -731,32 +727,26 @@ static int fsl_i2c_probe(struct platform_device *op)
}
dev_info(i2c->dev, "timeout %u us\n", mpc_ops.timeout * 100 / HZ);
- platform_set_drvdata(op, i2c);
-
i2c->adap = mpc_ops;
- of_address_to_resource(op->dev.of_node, 0, );
scnprintf(i2c->adap.name, sizeof(i2c->adap.name),
- "MPC adapter at 0x%llx", (unsigned long long)res.start);
- i2c_set_adapdata(>adap, i2c);
+ "MPC adapter (%s)", of_node_full_name(op->dev.of_node));
i2c->adap.dev.parent = >dev;
+ i2c->adap.nr = op->id;
i2c->adap.dev.of_node = of_node_get(op->dev.of_node);
i2c->adap.bus_recovery_info = _i2c_recovery_info;
+ platform_set_drvdata(op, i2c);
+ i2c_set_adapdata(>adap, i2c);
- result = i2c_add_adapter(>adap);
- if (result < 0)
+ result = i2c_add_numbered_adapter(>adap);
+ if (result)
goto fail_add;
- return result;
+ return 0;
fail_add:
if (i2c->clk_per)
clk_disable_unprepare(i2c->clk_per);
- free_irq(i2c->irq, i2c);
- fail_request:
- irq_dispose_mapping(i2c->irq);
- iounmap(i2c->base);
- fail_map:
- kfree(i2c);
+
return result;
};
--
2.30.2
[PATCH 6/6] i2c: mpc: Interrupt driven transfer
The fsl-i2c controller will generate an interrupt after every byte
transferred. Make use of this interrupt to drive a state machine which
allows the next part of a transfer to happen as soon as the interrupt is
received. This is particularly helpful with SMBUS devices like the LM81
which will timeout if we take too long between bytes in a transfer.
Signed-off-by: Chris Packham
---
drivers/i2c/busses/i2c-mpc.c | 430 +++
1 file changed, 237 insertions(+), 193 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 46cdb36e2f9b..5ffde3428232 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -1,16 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0
/*
- * (C) Copyright 2003-2004
- * Humboldt Solutions Ltd, adr...@humboldt.co.uk.
-
* This is a combined i2c adapter and algorithm driver for the
* MPC107/Tsi107 PowerPC northbridge and processors that include
* the same I2C unit (8240, 8245, 85xx).
*
- * Release 0.8
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2. This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
+ * Copyright (C) 2003-2004 Humboldt Solutions Ltd, adr...@humboldt.co.uk
+ * Copyright (C) 2021 Allied Telesis Labs
*/
#include
@@ -58,11 +53,32 @@
#define CSR_MIF 0x02
#define CSR_RXAK 0x01
+enum mpc_i2c_action {
+ MPC_I2C_ACTION_INVALID = 0,
+ MPC_I2C_ACTION_START,
+ MPC_I2C_ACTION_RESTART,
+ MPC_I2C_ACTION_READ_BEGIN,
+ MPC_I2C_ACTION_READ_BYTE,
+ MPC_I2C_ACTION_WRITE,
+ MPC_I2C_ACTION_STOP,
+};
+
+static char *action_str[] = {
+ "invalid",
+ "start",
+ "restart",
+ "read begin",
+ "read",
+ "write",
+ "stop",
+};
+
struct mpc_i2c {
struct device *dev;
void __iomem *base;
u32 interrupt;
- wait_queue_head_t queue;
+ wait_queue_head_t waitq;
+ spinlock_t lock;
struct i2c_adapter adap;
int irq;
u32 real_clk;
@@ -70,6 +86,16 @@ struct mpc_i2c {
u8 fdr, dfsrr;
#endif
struct clk *clk_per;
+ u32 cntl_bits;
+ enum mpc_i2c_action action;
+ struct i2c_msg *msgs;
+ int num_msgs;
+ int curr_msg;
+ u32 byte_posn;
+ u32 block;
+ int rc;
+ int expect_rxack;
+
};
struct mpc_i2c_divider {
@@ -86,19 +112,6 @@ static inline void writeccr(struct mpc_i2c *i2c, u32 x)
writeb(x, i2c->base + MPC_I2C_CR);
}
-static irqreturn_t mpc_i2c_isr(int irq, void *dev_id)
-{
- struct mpc_i2c *i2c = dev_id;
- if (readb(i2c->base + MPC_I2C_SR) & CSR_MIF) {
- /* Read again to allow register to stabilise */
- i2c->interrupt = readb(i2c->base + MPC_I2C_SR);
- writeb(0, i2c->base + MPC_I2C_SR);
- wake_up(>queue);
- return IRQ_HANDLED;
- }
- return IRQ_NONE;
-}
-
/* Sometimes 9th clock pulse isn't generated, and slave doesn't release
* the bus, because it wants to send ACK.
* Following sequence of enabling/disabling and sending start/stop generates
@@ -121,45 +134,6 @@ static void mpc_i2c_fixup(struct mpc_i2c *i2c)
}
}
-static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
-{
- u32 cmd_err;
- int result;
-
- result = wait_event_timeout(i2c->queue,
- (i2c->interrupt & CSR_MIF), timeout);
-
- if (unlikely(!(i2c->interrupt & CSR_MIF))) {
- dev_dbg(i2c->dev, "wait timeout\n");
- writeccr(i2c, 0);
- result = -ETIMEDOUT;
- }
-
- cmd_err = i2c->interrupt;
- i2c->interrupt = 0;
-
- if (result < 0)
- return result;
-
- if (!(cmd_err & CSR_MCF)) {
- dev_dbg(i2c->dev, "unfinished\n");
- return -EIO;
- }
-
- if (cmd_err & CSR_MAL) {
- dev_dbg(i2c->dev, "MAL\n");
- return -EAGAIN;
- }
-
- if (writing && (cmd_err & CSR_RXAK)) {
- dev_dbg(i2c->dev, "No RXAK\n");
- /* generate stop */
- writeccr(i2c, CCR_MEN);
- return -ENXIO;
- }
- return 0;
-}
-
#if defined(CONFIG_PPC_MPC52xx) || defined(CONFIG_PPC_MPC512x)
static const struct mpc_i2c_divider mpc_i2c_dividers_52xx[] = {
{20, 0x20}, {22, 0x21}, {24, 0x22}, {26, 0x23},
@@ -434,168 +408,209 @@ static void mpc_i2c_setup_8xxx(struct device_node *node,
}
#endif /* CONFIG_FSL_SOC */
-static void mpc_i2c_start(struct mpc_i2c *i2c)
+static void mpc_i2c_finish(struct mpc_i2c *i2c, int rc)
{
- /* Clear arbitration */
- writeb(0, i2c->base + MPC_I2C_SR);
- /* Start with MEN */
- writeccr(i2c, CCR_MEN);
+ i2c->rc = rc;
+ i2c->block = 0;
+ i2c->cntl_bits = CCR_MEN;
+ writeccr(i2c, i2c->cntl_bits);
+
[PATCH 3/6] i2c: mpc: Make use of i2c_recover_bus()
Move the existing calls of mpc_i2c_fixup() to a recovery function
registered via bus_recovery_info. This makes it more obvious that
recovery is supported and allows for a future where recovery is
triggered by the i2c core.
Signed-off-by: Chris Packham
---
drivers/i2c/busses/i2c-mpc.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index d94f05c8b8b7..6a0d55e9e8e3 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -586,7 +586,7 @@ static int mpc_xfer(struct i2c_adapter *adap, struct
i2c_msg *msgs, int num)
if ((status & (CSR_MCF | CSR_MBB | CSR_RXAK)) != 0) {
writeb(status & ~CSR_MAL,
i2c->base + MPC_I2C_SR);
- mpc_i2c_fixup(i2c);
+ i2c_recover_bus(>adap);
}
return -EIO;
}
@@ -622,7 +622,7 @@ static int mpc_xfer(struct i2c_adapter *adap, struct
i2c_msg *msgs, int num)
if ((status & (CSR_MCF | CSR_MBB | CSR_RXAK)) != 0) {
writeb(status & ~CSR_MAL,
i2c->base + MPC_I2C_SR);
- mpc_i2c_fixup(i2c);
+ i2c_recover_bus(>adap);
}
return -EIO;
}
@@ -637,6 +637,15 @@ static u32 mpc_functionality(struct i2c_adapter *adap)
| I2C_FUNC_SMBUS_READ_BLOCK_DATA | I2C_FUNC_SMBUS_BLOCK_PROC_CALL;
}
+static int fsl_i2c_bus_recovery(struct i2c_adapter *adap)
+{
+ struct mpc_i2c *i2c = i2c_get_adapdata(adap);
+
+ mpc_i2c_fixup(i2c);
+
+ return 0;
+}
+
static const struct i2c_algorithm mpc_algo = {
.master_xfer = mpc_xfer,
.functionality = mpc_functionality,
@@ -648,6 +657,10 @@ static struct i2c_adapter mpc_ops = {
.timeout = HZ,
};
+static struct i2c_bus_recovery_info fsl_i2c_recovery_info = {
+ .recover_bus = fsl_i2c_bus_recovery,
+};
+
static const struct of_device_id mpc_i2c_of_match[];
static int fsl_i2c_probe(struct platform_device *op)
{
@@ -740,6 +753,7 @@ static int fsl_i2c_probe(struct platform_device *op)
i2c_set_adapdata(>adap, i2c);
i2c->adap.dev.parent = >dev;
i2c->adap.dev.of_node = of_node_get(op->dev.of_node);
+ i2c->adap.bus_recovery_info = _i2c_recovery_info;
result = i2c_add_adapter(>adap);
if (result < 0)
--
2.30.2
[PATCH 0/6] i2c: mpc: Refactor to improve responsiveness
The "meat" of this series is in the last patch which is the change that actually starts making use of the interrupts to drive a state machine. The dt-bindings patches can probably go in at any time. The rest of the series isn't dependent on them. I've tested it on a T2081 based system with a number of i2c and smbus devices. Its the end of my work day so I figured I'd get this out now but I'll do some more testing on a P2041 board and a few different i2c devices tomorrow. Chris Packham (6): dt-bindings: i2c-mpc: Document interrupt property as required dt-bindings: i2c: convert i2c-mpc to json-schema i2c: mpc: Make use of i2c_recover_bus() i2c: mpc: make interrupt mandatory and remove polling code i2c: mpc: use device managed APIs i2c: mpc: Interrupt driven transfer .../devicetree/bindings/i2c/i2c-mpc.txt | 62 --- .../devicetree/bindings/i2c/i2c-mpc.yaml | 99 drivers/i2c/busses/i2c-mpc.c | 513 ++ 3 files changed, 373 insertions(+), 301 deletions(-) delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-mpc.txt create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mpc.yaml -- 2.30.2
[PATCH 2/6] dt-bindings: i2c: convert i2c-mpc to json-schema
Convert i2c-mpc to YAML.
Signed-off-by: Chris Packham
---
.../devicetree/bindings/i2c/i2c-mpc.txt | 62
.../devicetree/bindings/i2c/i2c-mpc.yaml | 99 +++
2 files changed, 99 insertions(+), 62 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-mpc.txt
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mpc.yaml
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mpc.txt
b/Documentation/devicetree/bindings/i2c/i2c-mpc.txt
deleted file mode 100644
index b15acb43d84d..
--- a/Documentation/devicetree/bindings/i2c/i2c-mpc.txt
+++ /dev/null
@@ -1,62 +0,0 @@
-* I2C
-
-Required properties :
-
- - reg : Offset and length of the register set for the device
- - compatible : should be "fsl,CHIP-i2c" where CHIP is the name of a
- compatible processor, e.g. mpc8313, mpc8543, mpc8544, mpc5121,
- mpc5200 or mpc5200b. For the mpc5121, an additional node
- "fsl,mpc5121-i2c-ctrl" is required as shown in the example below.
- - interrupts : where a is the interrupt number and b is a
- field that represents an encoding of the sense and level
- information for the interrupt. This should be encoded based on
- the information in section 2) depending on the type of interrupt
- controller you have.
-
-Recommended properties :
-
- - fsl,preserve-clocking : boolean; if defined, the clock settings
- from the bootloader are preserved (not touched).
- - clock-frequency : desired I2C bus clock frequency in Hz.
- - fsl,timeout : I2C bus timeout in microseconds.
-
-Examples :
-
- /* MPC5121 based board */
- i2c@1740 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "fsl,mpc5121-i2c", "fsl-i2c";
- reg = <0x1740 0x20>;
- interrupts = <11 0x8>;
- interrupt-parent = <>;
- clock-frequency = <10>;
- };
-
- i2ccontrol@1760 {
- compatible = "fsl,mpc5121-i2c-ctrl";
- reg = <0x1760 0x8>;
- };
-
- /* MPC5200B based board */
- i2c@3d00 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
- reg = <0x3d00 0x40>;
- interrupts = <2 15 0>;
- interrupt-parent = <_pic>;
- fsl,preserve-clocking;
- };
-
- /* MPC8544 base board */
- i2c@3100 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "fsl,mpc8544-i2c", "fsl-i2c";
- reg = <0x3100 0x100>;
- interrupts = <43 2>;
- interrupt-parent = <>;
- clock-frequency = <40>;
- fsl,timeout = <1>;
- };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml
b/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml
new file mode 100644
index ..97cea8a817ea
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/i2c-mpc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: I2C-Bus adapter for MPC824x/83xx/85xx/86xx/512x/52xx SoCs
+
+maintainers:
+ - Chris Packham
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+anyOf:
+ - items:
+- enum:
+ - mpc5200-i2c
+ - fsl,mpc5200b-i2c
+ - fsl,mpc5200-i2c
+ - fsl,mpc5121-i2c
+ - fsl,mpc8313-i2c
+ - fsl,mpc8543-i2c
+ - fsl,mpc8544-i2c
+
+- const: fsl-i2c
+
+ - contains:
+ const: fsl-i2c
+minItems: 1
+maxItems: 4
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ fsl,preserve-clocking:
+$ref: /schemas/types.yaml#/definitions/flag
+description: |
+ if defined, the clock settings from the bootloader are
+ preserved (not touched)
+
+ fsl,timeout:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: |
+ I2C bus timeout in microseconds
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+/* MPC5121 based board */
+i2c@1740 {
+#address-cells = <1>;
+#size-cells = <0>;
+compatible = "fsl,mpc5121-i2c", "fsl-i2c";
+reg = <0x1740 0x20>;
+interrupts = <11 0x8>;
+interrupt-parent = <>;
+clock-frequency = <10>;
+};
+
+i2ccontrol@1760 {
+compatible = "fsl,mpc5121-i2c-ctrl";
+reg = <0x1760 0x8>;
+};
+
+/* MPC5200B based board */
+i2c@3d00 {
+#address-cells = <1>;
+#size-cells = <0>;
+compatible = "fsl,mpc5200b-i2c", "fsl,mpc5200-i2c", "fsl-i2c";
+reg = <0x3d00 0x40>;
+interrupts = <2 15 0>;
+interrupt-parent = <_pic>;
+
[PATCH 1/6] dt-bindings: i2c-mpc: Document interrupt property as required
All of the in-tree device-trees that use the one of the compatible strings from i2c-mpc.c supply an interrupts property. Make this property mandatory to aid refactoring the driver. Signed-off-by: Chris Packham --- Documentation/devicetree/bindings/i2c/i2c-mpc.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/i2c/i2c-mpc.txt b/Documentation/devicetree/bindings/i2c/i2c-mpc.txt index 42a390526957..b15acb43d84d 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mpc.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mpc.txt @@ -7,14 +7,14 @@ Required properties : compatible processor, e.g. mpc8313, mpc8543, mpc8544, mpc5121, mpc5200 or mpc5200b. For the mpc5121, an additional node "fsl,mpc5121-i2c-ctrl" is required as shown in the example below. - -Recommended properties : - - interrupts : where a is the interrupt number and b is a field that represents an encoding of the sense and level information for the interrupt. This should be encoded based on the information in section 2) depending on the type of interrupt controller you have. + +Recommended properties : + - fsl,preserve-clocking : boolean; if defined, the clock settings from the bootloader are preserved (not touched). - clock-frequency : desired I2C bus clock frequency in Hz. -- 2.30.2
[PATCH 4/6] i2c: mpc: make interrupt mandatory and remove polling code
All the in-tree dts files that use one of the compatible strings from
i2c-mpc.c provide an interrupt property. By making this mandatory we
can simplify the code.
Signed-off-by: Chris Packham
---
drivers/i2c/busses/i2c-mpc.c | 51 ++--
1 file changed, 19 insertions(+), 32 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 6a0d55e9e8e3..5b746a898e8e 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -123,37 +123,21 @@ static void mpc_i2c_fixup(struct mpc_i2c *i2c)
static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
{
- unsigned long orig_jiffies = jiffies;
u32 cmd_err;
- int result = 0;
+ int result;
- if (!i2c->irq) {
- while (!(readb(i2c->base + MPC_I2C_SR) & CSR_MIF)) {
- schedule();
- if (time_after(jiffies, orig_jiffies + timeout)) {
- dev_dbg(i2c->dev, "timeout\n");
- writeccr(i2c, 0);
- result = -ETIMEDOUT;
- break;
- }
- }
- cmd_err = readb(i2c->base + MPC_I2C_SR);
- writeb(0, i2c->base + MPC_I2C_SR);
- } else {
- /* Interrupt mode */
- result = wait_event_timeout(i2c->queue,
+ result = wait_event_timeout(i2c->queue,
(i2c->interrupt & CSR_MIF), timeout);
- if (unlikely(!(i2c->interrupt & CSR_MIF))) {
- dev_dbg(i2c->dev, "wait timeout\n");
- writeccr(i2c, 0);
- result = -ETIMEDOUT;
- }
-
- cmd_err = i2c->interrupt;
- i2c->interrupt = 0;
+ if (unlikely(!(i2c->interrupt & CSR_MIF))) {
+ dev_dbg(i2c->dev, "wait timeout\n");
+ writeccr(i2c, 0);
+ result = -ETIMEDOUT;
}
+ cmd_err = i2c->interrupt;
+ i2c->interrupt = 0;
+
if (result < 0)
return result;
@@ -694,13 +678,16 @@ static int fsl_i2c_probe(struct platform_device *op)
}
i2c->irq = irq_of_parse_and_map(op->dev.of_node, 0);
- if (i2c->irq) { /* no i2c->irq implies polling */
- result = request_irq(i2c->irq, mpc_i2c_isr,
-IRQF_SHARED, "i2c-mpc", i2c);
- if (result < 0) {
- dev_err(i2c->dev, "failed to attach interrupt\n");
- goto fail_request;
- }
+ if (i2c->irq < 0) {
+ result = i2c->irq;
+ goto fail_map;
+ }
+
+ result = request_irq(i2c->irq, mpc_i2c_isr,
+ IRQF_SHARED, "i2c-mpc", i2c);
+ if (result < 0) {
+ dev_err(i2c->dev, "failed to attach interrupt\n");
+ goto fail_request;
}
/*
--
2.30.2
Re: [PATCH v31 2/4] scsi: ufs: L2P map management for HPB read
On 2021-03-23 12:22, Can Guo wrote:
On 2021-03-22 17:11, Bean Huo wrote:
On Mon, 2021-03-22 at 15:54 +0900, Daejun Park wrote:
+ switch (rsp_field->hpb_op) {
+ case HPB_RSP_REQ_REGION_UPDATE:
+ if (data_seg_len != DEV_DATA_SEG_LEN)
+ dev_warn(>sdev_ufs_lu->sdev_dev,
+"%s: data seg length is not
same.\n",
+__func__);
+ ufshpb_rsp_req_region_update(hpb, rsp_field);
+ break;
+ case HPB_RSP_DEV_RESET:
+ dev_warn(>sdev_ufs_lu->sdev_dev,
+"UFS device lost HPB information during
PM.\n");
+ break;
Hi Deajun,
This series looks good to me. Just here I have one question. You
didn't
handle HPB_RSP_DEV_RESET, just a warning. Based on your SS UFS, how
to
handle HPB_RSP_DEV_RESET from the host side? Do you think we shoud
reset host side HPB entry as well or what else?
Bean
Same question here - I am still collecting feedbacks from flash vendors
about
what is recommanded host behavior on reception of HPB Op code 0x2,
since it
is not cleared defined in HPB2.0 specs.
Can Guo.
I think the question should be asked in the HPB2.0 patch, since in
HPB1.0 device
control mode, a HPB reset in device side does not impact anything in
host side -
host is not writing back any HPB entries to device anyways and HPB Read
cmd with
invalid HPB entries shall be treated as normal Read(10) cmd without any
problems.
Please correct me if I am wrong.
Thanks,
Can Guo.
[PATCH] octeontx2-af: cn10k: Few mundane typos fixed
s/preceeds/precedes/ .two different places
s/rsponse/response/
s/cetain/certain/
s/precison/precision/
Signed-off-by: Bhaskar Chowdhury
---
drivers/net/ethernet/marvell/octeontx2/af/mbox.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
b/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
index ea456099b33c..14a184c3f6a4 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
+++ b/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
@@ -74,13 +74,13 @@ struct otx2_mbox {
struct otx2_mbox_dev *dev;
};
-/* Header which preceeds all mbox messages */
+/* Header which precedes all mbox messages */
struct mbox_hdr {
u64 msg_size; /* Total msgs size embedded */
u16 num_msgs; /* No of msgs embedded */
};
-/* Header which preceeds every msg and is also part of it */
+/* Header which precedes every msg and is also part of it */
struct mbox_msghdr {
u16 pcifunc; /* Who's sending this msg */
u16 id; /* Mbox message ID */
@@ -277,7 +277,7 @@ struct msg_req {
struct mbox_msghdr hdr;
};
-/* Generic rsponse msg used a ack or response for those mbox
+/* Generic response msg used a ack or response for those mbox
* messages which doesn't have a specific rsp msg format.
*/
struct msg_rsp {
@@ -299,7 +299,7 @@ struct ready_msg_rsp {
/* Structure for requesting resource provisioning.
* 'modify' flag to be used when either requesting more
- * or to detach partial of a cetain resource type.
+ * or to detach partial of a certain resource type.
* Rest of the fields specify how many of what type to
* be attached.
* To request LFs from two blocks of same type this mailbox
@@ -489,7 +489,7 @@ struct cgx_set_link_mode_rsp {
};
#define RVU_LMAC_FEAT_FC BIT_ULL(0) /* pause frames */
-#define RVU_LMAC_FEAT_PTP BIT_ULL(1) /* precison time protocol */
+#define RVU_LMAC_FEAT_PTP BIT_ULL(1) /* precision time protocol */
#define RVU_MAC_VERSIONBIT_ULL(2)
#define RVU_MAC_CGXBIT_ULL(3)
#define RVU_MAC_RPMBIT_ULL(4)
--
2.31.0
RE: [PATCH v2] dt-binding: leds: Document leds-multi-gpio bindings
> -Original Message- > From: Rob Herring > Sent: 2021年3月23日 1:38 > My bot found errors running 'make dt_binding_check' on your patch: > > yamllint warnings/errors: > > dtschema/dtc warnings/errors: > /builds/robherring/linux-dt- > review/Documentation/devicetree/bindings/leds/leds-multi- > gpio.example.dt.yaml: gpios-led: led-states: 'oneOf' conditional failed, one > must be fixed: > [[0, 1, 2, 3]] is too short > [0, 1, 2, 3] is too long > From schema: /builds/robherring/linux-dt- > review/Documentation/devicetree/bindings/leds/leds-multi-gpio.yaml > Hi Rob, Thanks. Yes, now I can see the warning, but I could not understand what was wrong? Could you give some hint? Best Regards, Hermes
Re: [PATCH] drivers: scsi: Remove duplicate include of blkdev.h
On 2021-03-22 20:28, Wan Jiabing wrote: linux/blkdev.h has been included at line 18, so remove the duplicate include at line 27. Signed-off-by: Wan Jiabing --- drivers/scsi/ufs/ufshcd.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index c86760788c72..e8aa7de17d0a 100644 --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -24,7 +24,6 @@ #include "ufs_bsg.h" #include "ufshcd-crypto.h" #include -#include #define CREATE_TRACE_POINTS #include Someone has addressed it before you - check https://git.kernel.org/mkp/scsi/c/b4388e3db56a Can Guo.
Re: [PATCH v31 2/4] scsi: ufs: L2P map management for HPB read
On 2021-03-22 17:11, Bean Huo wrote:
On Mon, 2021-03-22 at 15:54 +0900, Daejun Park wrote:
+ switch (rsp_field->hpb_op) {
+ case HPB_RSP_REQ_REGION_UPDATE:
+ if (data_seg_len != DEV_DATA_SEG_LEN)
+ dev_warn(>sdev_ufs_lu->sdev_dev,
+"%s: data seg length is not
same.\n",
+__func__);
+ ufshpb_rsp_req_region_update(hpb, rsp_field);
+ break;
+ case HPB_RSP_DEV_RESET:
+ dev_warn(>sdev_ufs_lu->sdev_dev,
+"UFS device lost HPB information during
PM.\n");
+ break;
Hi Deajun,
This series looks good to me. Just here I have one question. You didn't
handle HPB_RSP_DEV_RESET, just a warning. Based on your SS UFS, how to
handle HPB_RSP_DEV_RESET from the host side? Do you think we shoud
reset host side HPB entry as well or what else?
Bean
Same question here - I am still collecting feedbacks from flash vendors
about
what is recommanded host behavior on reception of HPB Op code 0x2, since
it
is not cleared defined in HPB2.0 specs.
Can Guo.
Re: [PATCH] staging: wimax: Mundane typo fixes
On 3/22/21 6:06 PM, Bhaskar Chowdhury wrote: > > s/procesing/processing/ > s/comunication/communication/ > > Signed-off-by: Bhaskar Chowdhury drivers/staging/wimax/ is in the process of being deleted. > --- > drivers/staging/wimax/i2400m/driver.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/wimax/i2400m/driver.c > b/drivers/staging/wimax/i2400m/driver.c > index f5186458bb3d..162a92682977 100644 > --- a/drivers/staging/wimax/i2400m/driver.c > +++ b/drivers/staging/wimax/i2400m/driver.c -- ~Randy
[syzbot] possible deadlock in __loop_clr_fd
Hello,
syzbot found the following issue on:
HEAD commit:ba5b053a Add linux-next specific files for 20210318
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=10cfb406d0
kernel config: https://syzkaller.appspot.com/x/.config?x=cd6e556bdf0188e4
dashboard link: https://syzkaller.appspot.com/bug?extid=707d51092ab7b87b23df
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+707d51092ab7b87b2...@syzkaller.appspotmail.com
UDF-fs: warning (device loop4): udf_load_vrs: No VRS found
UDF-fs: Scanning with blocksize 4096 failed
==
WARNING: possible circular locking dependency detected
5.12.0-rc3-next-20210318-syzkaller #0 Not tainted
--
syz-executor.4/13936 is trying to acquire lock:
88805cb9b138 ((wq_completion)loop292057088){+.+.}-{0:0}, at:
flush_workqueue+0xe1/0x13e0 kernel/workqueue.c:2783
but task is already holding lock:
88801a730468 (>lo_mutex){+.+.}-{3:3}, at: __loop_clr_fd+0x95/0x14a0
drivers/block/loop.c:1278
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #6 (>lo_mutex){+.+.}-{3:3}:
__mutex_lock_common kernel/locking/mutex.c:952 [inline]
__mutex_lock+0x139/0x1120 kernel/locking/mutex.c:1099
lo_open drivers/block/loop.c:1983 [inline]
lo_open+0xa1/0x130 drivers/block/loop.c:1965
__blkdev_get+0x135/0xa30 fs/block_dev.c:1302
blkdev_get_by_dev fs/block_dev.c:1454 [inline]
blkdev_get_by_dev+0x26c/0x600 fs/block_dev.c:1422
blkdev_open+0x154/0x2b0 fs/block_dev.c:1551
do_dentry_open+0x4b9/0x11b0 fs/open.c:826
do_open fs/namei.c:3365 [inline]
path_openat+0x1c0e/0x27e0 fs/namei.c:3498
do_filp_open+0x17e/0x3c0 fs/namei.c:3525
do_sys_openat2+0x16d/0x420 fs/open.c:1187
do_sys_open fs/open.c:1203 [inline]
__do_sys_open fs/open.c:1211 [inline]
__se_sys_open fs/open.c:1207 [inline]
__x64_sys_open+0x119/0x1c0 fs/open.c:1207
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xae
-> #5 (loop_ctl_mutex){+.+.}-{3:3}:
__mutex_lock_common kernel/locking/mutex.c:952 [inline]
__mutex_lock+0x139/0x1120 kernel/locking/mutex.c:1099
loop_probe+0xc7/0x150 drivers/block/loop.c:2407
blk_request_module+0x111/0x1d0 block/genhd.c:769
blkdev_get_no_open+0x225/0x2b0 fs/block_dev.c:1368
blkdev_get_by_dev fs/block_dev.c:1440 [inline]
blkdev_get_by_dev+0x1f9/0x600 fs/block_dev.c:1422
blkdev_open+0x154/0x2b0 fs/block_dev.c:1551
do_dentry_open+0x4b9/0x11b0 fs/open.c:826
do_open fs/namei.c:3365 [inline]
path_openat+0x1c0e/0x27e0 fs/namei.c:3498
do_filp_open+0x17e/0x3c0 fs/namei.c:3525
do_sys_openat2+0x16d/0x420 fs/open.c:1187
do_sys_open fs/open.c:1203 [inline]
__do_sys_openat fs/open.c:1219 [inline]
__se_sys_openat fs/open.c:1214 [inline]
__x64_sys_openat+0x13f/0x1f0 fs/open.c:1214
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xae
-> #4 (major_names_lock){+.+.}-{3:3}:
__mutex_lock_common kernel/locking/mutex.c:952 [inline]
__mutex_lock+0x139/0x1120 kernel/locking/mutex.c:1099
blkdev_show+0x27/0x160 block/genhd.c:263
devinfo_show+0xc1/0xf0 fs/proc/devices.c:22
seq_read_iter+0xb66/0x1220 fs/seq_file.c:269
proc_reg_read_iter+0x1fb/0x2d0 fs/proc/inode.c:310
call_read_iter include/linux/fs.h:1969 [inline]
new_sync_read+0x41e/0x6e0 fs/read_write.c:415
vfs_read+0x35c/0x570 fs/read_write.c:496
ksys_read+0x12d/0x250 fs/read_write.c:634
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xae
-> #3 (>lock){+.+.}-{3:3}:
__mutex_lock_common kernel/locking/mutex.c:952 [inline]
__mutex_lock+0x139/0x1120 kernel/locking/mutex.c:1099
seq_read_iter+0xdf/0x1220 fs/seq_file.c:179
call_read_iter include/linux/fs.h:1969 [inline]
generic_file_splice_read+0x450/0x6c0 fs/splice.c:311
do_splice_to+0x1bf/0x250 fs/splice.c:796
splice_direct_to_actor+0x2c2/0x8c0 fs/splice.c:870
do_splice_direct+0x1b3/0x280 fs/splice.c:979
do_sendfile+0x9f0/0x1110 fs/read_write.c:1260
__do_sys_sendfile64 fs/read_write.c:1325 [inline]
__se_sys_sendfile64 fs/read_write.c:1311 [inline]
__x64_sys_sendfile64+0x1cc/0x210 fs/read_write.c:1311
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xae
-> #2 (sb_writers#3){.+.+}-{0:0}:
percpu_down_read include/linux/percpu-rwsem.h:51 [inline]
__sb_start_write include/linux/fs.h:1638 [inline]
sb_start_write
Re: GTE - The hardware timestamping engine
On 3/22/21 7:59 PM, Kent Gibson wrote: > On Mon, Mar 22, 2021 at 06:53:10PM -0700, Dipen Patel wrote: >> >> >> On 3/22/21 5:32 PM, Kent Gibson wrote: >>> On Mon, Mar 22, 2021 at 01:21:46PM -0700, Dipen Patel wrote: Hi Linus and Kent, > > [snip] > >>> In response to all your comments above... >>> >>> Firstly, I'm not suggesting that other kernel modules would use the >>> cdev lineevents, only that they would use the same mechanism that >>> gpiolib-cdev would use to timestamp the lineevents for userspace. >>> >> Sure, I just wanted to mention the different scenarios and wanted to know >> how can we fit all those together. Having said that, shouldn't this serve >> an opportunity to extend the linevent framework to accommodate kernel >> drivers as a clients? >> >> If we can't, then there is a risk of duplicating lineevent mechanism in all >> of those kernel drivers or at least in GTE framework/infrastructure as far >> as GPIO related GTE part is concerned. >> > > In-kernel the lineevents are just IRQs so anything needing a "lineevent" > can request the IRQ directly. Or am I missing something? > In the GPIO context, I meant we can extend line_event_timestamp to kernel drivers as well in that way, both userspace and kernel drivers requesting particular GPIO for the hardware timestamp would be managed by same lineevent_* infrastructure from the gpiolib. Something like lineevent_create version of the kernel drivers, so if they need hardware timestamp on the GPIO line, they can request with some flags. In that way, GTE can leverage linevent* codes from gpiolib to cover its both the GPIO related use cases i.e. userspace app and kernel drivers. >>> As to that mechanism, my current thinking is that the approach of >>> associating GTE event FIFO entries with particular physical IRQ events is >>> problematic, as keeping the two in sync would be difficult, if not >>> impossible. >>> >>> A more robust approach is to ignore the physical IRQs and instead service >>> the GTE event FIFO, generating IRQs from those events in software - >>> essentially a pre-timestamped IRQ. The IRQ framework could provide the >>> timestamping functionality, equivalent to line_event_timestamp(), for >>> the IRQ handler/thread and in this case provide the timestamp from the GTE >>> event. >>> >> >> I have not fully understood above two paragraphs (except about >> lineevent_event_timestamp related part). >> >> I have no idea what it means to "ignore the physical IRQs and service the >> GTE event FIFO". Just like GPIO clients, there could be IRQ clients which >> want to monitor certain IRQ line, like ethernet driver wanted to retrieve >> timestamp for its IRQ line and so on. >> > > I mean that in the IRQ framework, rather than enabling the physical IRQ > line it would leave that masked and would instead enable the FIFO line to > service the FIFO, configure the GTE to generate the events for that > line, and then generate IRQs in response to the FIFO events. > That way the client requesting the IRQ is guaranteed to only receive an > IRQ that corresponds to a GTE FIFO event and the timestamp stored in the > IRQ framework would match. > I do not think we need to do such things, for example, below is the rough sequence how GTE can notify its clients be it GPIO or IRQ lines. I believe this will also help understand better ongoing GPIO discussions. 1. Configure GTE FIFO watermark or threshold, lets assume 1, i.e generate GTE interrupt when FIFO depth is 1. 2. In the GTE ISR or ISR thread, drain internal FIFO entries 3. Through GTE driver's internal mapping, identify which IRQ or GPIO number this entry belongs to. (This is possible as GTE has predefined bits for each supported signals, for example GTE supports 40 GPIOs and 352 IRQ lines, and it has multliple GTE instances which can take care all of them) 4. GTE driver pushes the event data (in this case it will be timestamp and direction of the event ie.rising or falling) to the GTE generic framework 5. GTE framework will store per event data to its per client/event sw FIFO 6. wake up any sleeping client thread 7. Points 3 to 6 are happening in GTE ISR context. 8. gte_retrieve_event (which can block if no event) at later convenient time do whatever it wants with it. We can extend it to non blocking version where some sort of client callbacks can be implemented. > And that is what I mean by this being an IRQ feature. > We need feedback from the IRQ guys as to whether that makes sense to > them. > > Cheers, > Kent. > Best Regards, Dipen Patel
Re: [PATCH] coresight: core: Fix typo in coresight-core.c
On 2021/3/22 22:38, Suzuki K Poulose wrote:
On 22/03/2021 13:11, Qi Liu wrote:
Fix up one typo: compoment->component.
Fixes: 8e264c52e1da ("coresight: core: Allow the coresight core
driver to be built as a module")
Signed-off-by: Qi Liu
Thanks for the patch. I will queue this.
.
Hi Suzuki,
Randy pointed out it should be "components" here, so I'll send a v2 with
this fixed.
Thanks,
Qi
[PATCH v2] sched: Warn on long periods of pending need_resched
From: Paul Turner
CPU scheduler marks need_resched flag to signal a schedule() on a
particular CPU. But, schedule() may not happen immediately in cases
where the current task is executing in the kernel mode (no
preemption state) for extended periods of time.
This patch adds a warn_on if need_resched is pending for more than the
time specified in sysctl resched_latency_warn_ms. If it goes off, it is
likely that there is a missing cond_resched() somewhere. Monitoring is
done via the tick and the accuracy is hence limited to jiffy scale. This
also means that we won't trigger the warning if the tick is disabled.
This feature is default disabled. It can be toggled on using sysctl
resched_latency_warn_enabled.
Signed-off-by: Paul Turner
Signed-off-by: Josh Don
---
Delta from v1:
- separate sysctl for enabling/disabling and triggering warn_once
behavior
- add documentation
- static branch for the enable
Documentation/admin-guide/sysctl/kernel.rst | 23 ++
include/linux/sched/sysctl.h| 4 ++
kernel/sched/core.c | 78 -
kernel/sched/debug.c| 10 +++
kernel/sched/sched.h| 10 +++
kernel/sysctl.c | 24 +++
6 files changed, 148 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/sysctl/kernel.rst
b/Documentation/admin-guide/sysctl/kernel.rst
index 1d56a6b73a4e..2d4a21d3b79f 100644
--- a/Documentation/admin-guide/sysctl/kernel.rst
+++ b/Documentation/admin-guide/sysctl/kernel.rst
@@ -1077,6 +1077,29 @@ ROM/Flash boot loader. Maybe to tell it what to do after
rebooting. ???
+resched_latency_warn_enabled
+
+
+Enables/disables a warning that will trigger if need_resched is set for
+longer than sysctl ``resched_latency_warn_ms``. This warning likely
+indicates a kernel bug, such as a failure to call cond_resched().
+
+Requires ``CONFIG_SCHED_DEBUG``.
+
+
+resched_latency_warn_ms
+===
+
+See ``resched_latency_warn_enabled``.
+
+
+resched_latency_warn_once
+=
+
+If set, ``resched_latency_warn_enabled`` will only trigger one warning
+per boot.
+
+
sched_energy_aware
==
diff --git a/include/linux/sched/sysctl.h b/include/linux/sched/sysctl.h
index 3c31ba88aca5..43a1f5ab819a 100644
--- a/include/linux/sched/sysctl.h
+++ b/include/linux/sched/sysctl.h
@@ -48,6 +48,10 @@ extern unsigned int sysctl_numa_balancing_scan_size;
extern __read_mostly unsigned int sysctl_sched_migration_cost;
extern __read_mostly unsigned int sysctl_sched_nr_migrate;
+extern struct static_key_false resched_latency_warn_enabled;
+extern int sysctl_resched_latency_warn_ms;
+extern int sysctl_resched_latency_warn_once;
+
int sched_proc_update_handler(struct ctl_table *table, int write,
void *buffer, size_t *length, loff_t *ppos);
#endif
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 98191218d891..d69ae342b450 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -58,7 +58,21 @@ const_debug unsigned int sysctl_sched_features =
#include "features.h"
0;
#undef SCHED_FEAT
-#endif
+
+/*
+ * Print a warning if need_resched is set for the given duration (if
+ * resched_latency_warn_enabled is set).
+ *
+ * If sysctl_resched_latency_warn_once is set, only one warning will be shown
+ * per boot.
+ *
+ * Resched latency will be ignored for the first resched_boot_quiet_sec, to
+ * reduce false alarms.
+ */
+int sysctl_resched_latency_warn_ms = 100;
+int sysctl_resched_latency_warn_once = 1;
+const long resched_boot_quiet_sec = 600;
+#endif /* CONFIG_SCHED_DEBUG */
/*
* Number of tasks to iterate in a single balance run.
@@ -4520,6 +4534,58 @@ unsigned long long task_sched_runtime(struct task_struct
*p)
return ns;
}
+#ifdef CONFIG_SCHED_DEBUG
+static u64 resched_latency_check(struct rq *rq)
+{
+ int latency_warn_ms = READ_ONCE(sysctl_resched_latency_warn_ms);
+ u64 need_resched_latency, now = rq_clock(rq);
+ static bool warned_once;
+
+ if (sysctl_resched_latency_warn_once && warned_once)
+ return 0;
+
+ if (!need_resched() || WARN_ON_ONCE(latency_warn_ms < 2))
+ return 0;
+
+ /* Disable this warning for the first few mins after boot */
+ if (now < resched_boot_quiet_sec * NSEC_PER_SEC)
+ return 0;
+
+ if (!rq->last_seen_need_resched_ns) {
+ rq->last_seen_need_resched_ns = now;
+ rq->ticks_without_resched = 0;
+ return 0;
+ }
+
+ rq->ticks_without_resched++;
+ need_resched_latency = now - rq->last_seen_need_resched_ns;
+ if (need_resched_latency <= latency_warn_ms * NSEC_PER_MSEC)
+ return 0;
+
+ warned_once = true;
+
+ return need_resched_latency;
+}
+
+static int __init setup_resched_latency_warn_ms(char *str)
+{
+ long val;
+
+ if
[PATCH 4/4] Documentation/admin-guide/module-signing.rst: add openssl command option example for CodeSign EKU
Add an openssl command option example for generating CodeSign extended key usage in X.509 when CONFIG_CHECK_CODESIGN_EKU is enabled. Signed-off-by: "Lee, Chun-Yi" --- Documentation/admin-guide/module-signing.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/admin-guide/module-signing.rst b/Documentation/admin-guide/module-signing.rst index 7d7c7c8a545c..ca3b8f19466c 100644 --- a/Documentation/admin-guide/module-signing.rst +++ b/Documentation/admin-guide/module-signing.rst @@ -170,6 +170,12 @@ generate the public/private key files:: -config x509.genkey -outform PEM -out kernel_key.pem \ -keyout kernel_key.pem +When ``CONFIG_CHECK_CODESIGN_EKU`` option is enabled, the following openssl +command option should be added where for generating CodeSign extended key usage +in X.509:: + +-addext "extendedKeyUsage=codeSigning" + The full pathname for the resulting kernel_key.pem file can then be specified in the ``CONFIG_MODULE_SIG_KEY`` option, and the certificate and key therein will be used instead of an autogenerated keypair. -- 2.16.4
[PATCH 3/4] modsign: Add codeSigning EKU when generating X.509 key generation config
Add codeSigning EKU to the X.509 key generation config for the build time autogenerated kernel key. Signed-off-by: "Lee, Chun-Yi" --- certs/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/certs/Makefile b/certs/Makefile index f4c25b67aad9..1ef4d6ca43b7 100644 --- a/certs/Makefile +++ b/certs/Makefile @@ -88,6 +88,7 @@ $(obj)/x509.genkey: @echo >>$@ "keyUsage=digitalSignature" @echo >>$@ "subjectKeyIdentifier=hash" @echo >>$@ "authorityKeyIdentifier=keyid" + @echo >>$@ "extendedKeyUsage=codeSigning" endif # CONFIG_MODULE_SIG_KEY $(eval $(call config_filename,MODULE_SIG_KEY)) -- 2.16.4
[PATCH 2/4] PKCS#7: Check codeSigning EKU for kernel module and kexec pe verification
This patch adds the logic for checking the CodeSigning extended
key usage when verifying signature of kernel module or
kexec PE binary in PKCS#7.
Signed-off-by: "Lee, Chun-Yi"
---
certs/system_keyring.c | 2 +-
crypto/asymmetric_keys/Kconfig | 9 +
crypto/asymmetric_keys/pkcs7_trust.c | 37 +---
include/crypto/pkcs7.h | 3 ++-
4 files changed, 46 insertions(+), 5 deletions(-)
diff --git a/certs/system_keyring.c b/certs/system_keyring.c
index 4b693da488f1..c9f8bca0b0d3 100644
--- a/certs/system_keyring.c
+++ b/certs/system_keyring.c
@@ -243,7 +243,7 @@ int verify_pkcs7_message_sig(const void *data, size_t len,
goto error;
}
}
- ret = pkcs7_validate_trust(pkcs7, trusted_keys);
+ ret = pkcs7_validate_trust(pkcs7, trusted_keys, usage);
if (ret < 0) {
if (ret == -ENOKEY)
pr_devel("PKCS#7 signature not signed with a trusted
key\n");
diff --git a/crypto/asymmetric_keys/Kconfig b/crypto/asymmetric_keys/Kconfig
index 1f1f004dc757..1754812df989 100644
--- a/crypto/asymmetric_keys/Kconfig
+++ b/crypto/asymmetric_keys/Kconfig
@@ -96,4 +96,13 @@ config SIGNED_PE_FILE_VERIFICATION
This option provides support for verifying the signature(s) on a
signed PE binary.
+config CHECK_CODESIGN_EKU
+ bool "Check codeSigning extended key usage"
+ depends on PKCS7_MESSAGE_PARSER=y
+ depends on SYSTEM_DATA_VERIFICATION
+ help
+ This option provides support for checking the codeSigning extended
+ key usage when verifying the signature in PKCS#7. It affects kernel
+ module verification and kexec PE binary verification.
+
endif # ASYMMETRIC_KEY_TYPE
diff --git a/crypto/asymmetric_keys/pkcs7_trust.c
b/crypto/asymmetric_keys/pkcs7_trust.c
index b531df2013c4..077bfef928b6 100644
--- a/crypto/asymmetric_keys/pkcs7_trust.c
+++ b/crypto/asymmetric_keys/pkcs7_trust.c
@@ -16,12 +16,36 @@
#include
#include "pkcs7_parser.h"
+#ifdef CONFIG_CHECK_CODESIGN_EKU
+static bool check_codesign_eku(struct key *key,
+enum key_being_used_for usage)
+{
+ struct public_key *public_key = key->payload.data[asym_crypto];
+
+ switch (usage) {
+ case VERIFYING_MODULE_SIGNATURE:
+ case VERIFYING_KEXEC_PE_SIGNATURE:
+ return !!(public_key->eku & EKU_codeSigning);
+ default:
+ break;
+ }
+ return true;
+}
+#else
+static bool check_codesign_eku(struct key *key,
+enum key_being_used_for usage)
+{
+ return true;
+}
+#endif
+
/*
* Check the trust on one PKCS#7 SignedInfo block.
*/
static int pkcs7_validate_trust_one(struct pkcs7_message *pkcs7,
struct pkcs7_signed_info *sinfo,
- struct key *trust_keyring)
+ struct key *trust_keyring,
+ enum key_being_used_for usage)
{
struct public_key_signature *sig = sinfo->sig;
struct x509_certificate *x509, *last = NULL, *p;
@@ -112,6 +136,12 @@ static int pkcs7_validate_trust_one(struct pkcs7_message
*pkcs7,
return -ENOKEY;
matched:
+ if (!check_codesign_eku(key, usage)) {
+ pr_warn("sinfo %u: The signer %x key is not CodeSigning\n",
+ sinfo->index, key_serial(key));
+ key_put(key);
+ return -ENOKEY;
+ }
ret = verify_signature(key, sig);
key_put(key);
if (ret < 0) {
@@ -156,7 +186,8 @@ static int pkcs7_validate_trust_one(struct pkcs7_message
*pkcs7,
* May also return -ENOMEM.
*/
int pkcs7_validate_trust(struct pkcs7_message *pkcs7,
-struct key *trust_keyring)
+struct key *trust_keyring,
+enum key_being_used_for usage)
{
struct pkcs7_signed_info *sinfo;
struct x509_certificate *p;
@@ -167,7 +198,7 @@ int pkcs7_validate_trust(struct pkcs7_message *pkcs7,
p->seen = false;
for (sinfo = pkcs7->signed_infos; sinfo; sinfo = sinfo->next) {
- ret = pkcs7_validate_trust_one(pkcs7, sinfo, trust_keyring);
+ ret = pkcs7_validate_trust_one(pkcs7, sinfo, trust_keyring,
usage);
switch (ret) {
case -ENOKEY:
continue;
diff --git a/include/crypto/pkcs7.h b/include/crypto/pkcs7.h
index 38ec7f5f9041..b3b48240ba73 100644
--- a/include/crypto/pkcs7.h
+++ b/include/crypto/pkcs7.h
@@ -30,7 +30,8 @@ extern int pkcs7_get_content_data(const struct pkcs7_message
*pkcs7,
* pkcs7_trust.c
*/
extern int pkcs7_validate_trust(struct pkcs7_message *pkcs7,
- struct key *trust_keyring);
+ struct key *trust_keyring,
+
[PATCH 1/4] X.509: Add CodeSigning extended key usage parsing
This patch adds the logic for parsing the CodeSign extended key usage
extension in X.509. The parsing result will be set to the eku flag
which is carried by public key. It can be used in the PKCS#7
verification.
Signed-off-by: "Lee, Chun-Yi"
---
crypto/asymmetric_keys/x509_cert_parser.c | 24
include/crypto/public_key.h | 1 +
include/linux/oid_registry.h | 5 +
3 files changed, 30 insertions(+)
diff --git a/crypto/asymmetric_keys/x509_cert_parser.c
b/crypto/asymmetric_keys/x509_cert_parser.c
index 52c9b455fc7d..65721313b265 100644
--- a/crypto/asymmetric_keys/x509_cert_parser.c
+++ b/crypto/asymmetric_keys/x509_cert_parser.c
@@ -497,6 +497,8 @@ int x509_process_extension(void *context, size_t hdrlen,
struct x509_parse_context *ctx = context;
struct asymmetric_key_id *kid;
const unsigned char *v = value;
+ int i = 0;
+ enum OID oid;
pr_debug("Extension: %u\n", ctx->last_oid);
@@ -526,6 +528,28 @@ int x509_process_extension(void *context, size_t hdrlen,
return 0;
}
+ if (ctx->last_oid == OID_extKeyUsage) {
+ if (v[0] != ((ASN1_UNIV << 6) | ASN1_CONS_BIT | ASN1_SEQ) ||
+ v[1] != vlen - 2)
+ return -EBADMSG;
+ i += 2;
+
+ while (i < vlen) {
+ /* A 10 bytes EKU OID Octet blob =
+* ASN1_OID + size byte + 8 bytes OID */
+ if (v[i] != ASN1_OID || v[i + 1] != 8 || (i + 10) >
vlen)
+ return -EBADMSG;
+
+ oid = look_up_OID(v + i + 2, v[i + 1]);
+ if (oid == OID_codeSigning) {
+ ctx->cert->pub->eku |= EKU_codeSigning;
+ }
+ i += 10;
+ }
+ pr_debug("extKeyUsage: %d\n", ctx->cert->pub->eku);
+ return 0;
+ }
+
return 0;
}
diff --git a/include/crypto/public_key.h b/include/crypto/public_key.h
index 47accec68cb0..1ccaebe2a28b 100644
--- a/include/crypto/public_key.h
+++ b/include/crypto/public_key.h
@@ -28,6 +28,7 @@ struct public_key {
bool key_is_private;
const char *id_type;
const char *pkey_algo;
+ unsigned int eku : 9; /* Extended Key Usage (9-bit) */
};
extern void public_key_free(struct public_key *key);
diff --git a/include/linux/oid_registry.h b/include/linux/oid_registry.h
index 4462ed2c18cd..e20e8eb53b21 100644
--- a/include/linux/oid_registry.h
+++ b/include/linux/oid_registry.h
@@ -113,9 +113,14 @@ enum OID {
OID_SM2_with_SM3, /* 1.2.156.10197.1.501 */
OID_sm3WithRSAEncryption, /* 1.2.156.10197.1.504 */
+ /* Extended key purpose OIDs [RFC 5280] */
+ OID_codeSigning,/* 1.3.6.1.5.5.7.3.3 */
+
OID__NR
};
+#define EKU_codeSigning(1 << 2)
+
extern enum OID look_up_OID(const void *data, size_t datasize);
extern int sprint_oid(const void *, size_t, char *, size_t);
extern int sprint_OID(enum OID, char *, size_t);
--
2.16.4
[PATCH v5 0/4] Check codeSigning extended key usage extension
NIAP PP_OS certification requests that the OS shall validate the CodeSigning extended key usage extension field for integrity verifiction of exectable code: https://www.niap-ccevs.org/MMO/PP/-442-/ FIA_X509_EXT.1.1 This patchset adds the logic for parsing the codeSigning EKU extension field in X.509. And checking the CodeSigning EKU when verifying signature of kernel module or kexec PE binary in PKCS#7. v5: Fixed the wording in module-signing.rst. v4: Fixed the wording in patch description. v3: - Add codeSigning EKU to x509.genkey key generation config. - Add openssl command option example for generating CodeSign EKU to module-signing.rst document. v2: Changed the help wording in the Kconfig. Lee, Chun-Yi (4): X.509: Add CodeSigning extended key usage parsing PKCS#7: Check codeSigning EKU for kernel module and kexec pe verification modsign: Add codeSigning EKU when generating X.509 key generation config Documentation/admin-guide/module-signing.rst: add openssl command option example for CodeSign EKU Documentation/admin-guide/module-signing.rst | 6 + certs/Makefile | 1 + certs/system_keyring.c | 2 +- crypto/asymmetric_keys/Kconfig | 9 +++ crypto/asymmetric_keys/pkcs7_trust.c | 37 +--- crypto/asymmetric_keys/x509_cert_parser.c| 24 ++ include/crypto/pkcs7.h | 3 ++- include/crypto/public_key.h | 1 + include/linux/oid_registry.h | 5 9 files changed, 83 insertions(+), 5 deletions(-) -- 2.16.4
Re: [PATCH 1/6] sched: migration changes for core scheduling
On 2021/3/22 20:56, Peter Zijlstra wrote:
> On Mon, Mar 22, 2021 at 08:31:09PM +0800, Li, Aubrey wrote:
>> Please let me know if I put cookie match check at the right position
>> in task_hot(), if so, I'll obtain some performance data of it.
>>
>> Thanks,
>> -Aubrey
>>
>> ===
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 7f2fb08..d4bdcf9 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -1912,6 +1912,13 @@ static void task_numa_find_cpu(struct task_numa_env
>> *env,
>> if (!cpumask_test_cpu(cpu, env->p->cpus_ptr))
>> continue;
>>
>> +/*
>> + * Skip this cpu if source task's cookie does not match
>> + * with CPU's core cookie.
>> + */
>> +if (!sched_core_cookie_match(cpu_rq(cpu), env->p))
>> +continue;
>> +
>> env->dst_cpu = cpu;
>> if (task_numa_compare(env, taskimp, groupimp, maymove))
>> break;
>
> This one might need a little help too, I've not fully considered NUMA
> balancing though.
>
I dropped this numa change for now as it may be too strong, too. I'll
do more experiment about this on the new iteration.
The following patch is rebased on top of queue tree, cookie check is moved
from can_migrate_task to task_hot.
please let me know if any issues.
Thanks,
-Aubrey
==
>From 70d0ed9bab658b0bad60fda73f81b747f20975f0 Mon Sep 17 00:00:00 2001
From: Aubrey Li
Date: Tue, 23 Mar 2021 03:26:34 +
Subject: [PATCH] sched: migration changes for core scheduling
- Don't migrate if there is a cookie mismatch
Load balance tries to move task from busiest CPU to the
destination CPU. When core scheduling is enabled, if the
task's cookie does not match with the destination CPU's
core cookie, this task may be skipped by this CPU. This
mitigates the forced idle time on the destination CPU.
- Select cookie matched idle CPU
In the fast path of task wakeup, select the first cookie matched
idle CPU instead of the first idle CPU.
- Find cookie matched idlest CPU
In the slow path of task wakeup, find the idlest CPU whose core
cookie matches with task's cookie
Signed-off-by: Aubrey Li
Signed-off-by: Tim Chen
Signed-off-by: Vineeth Remanan Pillai
Signed-off-by: Joel Fernandes (Google)
---
kernel/sched/fair.c | 29 ++
kernel/sched/sched.h | 73
2 files changed, 96 insertions(+), 6 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index efde8df2bc35..a74061484194 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5877,11 +5877,15 @@ find_idlest_group_cpu(struct sched_group *group, struct
task_struct *p, int this
/* Traverse only the allowed CPUs */
for_each_cpu_and(i, sched_group_span(group), p->cpus_ptr) {
+ struct rq *rq = cpu_rq(i);
+
+ if (!sched_core_cookie_match(rq, p))
+ continue;
+
if (sched_idle_cpu(i))
return i;
if (available_idle_cpu(i)) {
- struct rq *rq = cpu_rq(i);
struct cpuidle_state *idle = idle_get_state(rq);
if (idle && idle->exit_latency < min_exit_latency) {
/*
@@ -5967,9 +5971,10 @@ static inline int find_idlest_cpu(struct sched_domain
*sd, struct task_struct *p
return new_cpu;
}
-static inline int __select_idle_cpu(int cpu)
+static inline int __select_idle_cpu(int cpu, struct task_struct *p)
{
- if (available_idle_cpu(cpu) || sched_idle_cpu(cpu))
+ if ((available_idle_cpu(cpu) || sched_idle_cpu(cpu)) &&
+ sched_cpu_cookie_match(cpu_rq(cpu), p))
return cpu;
return -1;
@@ -6039,7 +6044,7 @@ static int select_idle_core(struct task_struct *p, int
core, struct cpumask *cpu
int cpu;
if (!static_branch_likely(_smt_present))
- return __select_idle_cpu(core);
+ return __select_idle_cpu(core, p);
for_each_cpu(cpu, cpu_smt_mask(core)) {
if (!available_idle_cpu(cpu)) {
@@ -6077,7 +6082,7 @@ static inline bool test_idle_cores(int cpu, bool def)
static inline int select_idle_core(struct task_struct *p, int core, struct
cpumask *cpus, int *idle_cpu)
{
- return __select_idle_cpu(core);
+ return __select_idle_cpu(core, p);
}
#endif /* CONFIG_SCHED_SMT */
@@ -6130,7 +6135,7 @@ static int select_idle_cpu(struct task_struct *p, struct
sched_domain *sd, int t
} else {
if (!--nr)
return -1;
- idle_cpu = __select_idle_cpu(cpu);
+ idle_cpu = __select_idle_cpu(cpu, p);
Re: [PATCH V2 0/6] PM / devfreq: a few small fixes and improvements
Hi, On 3/23/21 12:25 PM, Dong Aisheng wrote: > Hi Chanwoo, > > On Tue, Mar 23, 2021 at 11:13 AM Dong Aisheng wrote: >> >> A few small fixes and improvements >> >> ChangeLog: >> v1->v2: >> * squash a few patches >> * rebase to devfreq-testing > > I have to rebase to devfreq-testing instead of devfreq-next because > below two patches > only exist in devfreq-testing. > 5cc75e9252e9 (devfreq/devfreq-testing) PM / devfreq: Add > devfreq_transitions debugfs file > dc9e557845c1 PM / devfreq: Add new up_threshold and down_differential > sysfs attrs > My patch 5 needs change based on it according to your suggestion. So i have to > rebase to that branch. > > However, i found devfreq-testing can't build with GOV_PASSVIE enabled. > Patch 1 fixed it. You can squash to the original one when apply. > > Please help take a look at this new series. Please rebase your patches either devfreq-next or linux-next.git Because devfreq-testing branch is not official. > Thanks > > Regards > Aisheng > >> * drop two patches which are already in devfreq-next >> >> Dong Aisheng (6): >> PM / devfreq: fix build error when DEVFREQ_GOV_PASSIVE enabled >> PM / devfreq: Use more accurate returned new_freq as resume_freq >> PM / devfreq: Remove the invalid description for get_target_freq >> PM / devfreq: bail out early if no freq changes in devfreq_set_target >> PM / devfreq: governor: optimize simpleondemand get_target_freq >> PM / devfreq: imx8m-ddrc: remove imx8m_ddrc_get_dev_status >> >> Documentation/ABI/testing/sysfs-class-devfreq | 5 +-- >> drivers/devfreq/devfreq.c | 37 +++ >> drivers/devfreq/governor.h| 2 - >> drivers/devfreq/governor_simpleondemand.c | 31 ++-- >> drivers/devfreq/imx8m-ddrc.c | 14 --- >> 5 files changed, 35 insertions(+), 54 deletions(-) >> >> -- >> 2.25.1 >> > > -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH] coresight: core: Fix typo in coresight-core.c
On 2021/3/23 0:55, Randy Dunlap wrote:
On 3/22/21 7:38 AM, Suzuki K Poulose wrote:
On 22/03/2021 13:11, Qi Liu wrote:
Fix up one typo: compoment->component.
Fixes: 8e264c52e1da ("coresight: core: Allow the coresight core driver to be built
as a module")
Signed-off-by: Qi Liu
Thanks for the patch. I will queue this.
should be "both components"
Thanks,will fix it next version.
Qi
[PATCH] usb: Add data checks in usbtmc_disconnect
In usbtmc_disconnect, data is got from intf with the initial reference. There is no refcount inc operation before usbmc_free_int(data). In usbmc_free_int(data), the data may be freed. But later in usbtmc_disconnect, there is another put function of data. I think it is better to add necessary checks to avoid the data being put twice. It could cause errors in race. Signed-off-by: Lv Yunlong --- drivers/usb/class/usbtmc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c index 74d5a9c5238a..e0438cb46386 100644 --- a/drivers/usb/class/usbtmc.c +++ b/drivers/usb/class/usbtmc.c @@ -2494,7 +2494,9 @@ static void usbtmc_disconnect(struct usb_interface *intf) } mutex_unlock(>io_mutex); usbtmc_free_int(data); - kref_put(>kref, usbtmc_delete); + + if (data->iin_ep_present && data->iin_urb) + kref_put(>kref, usbtmc_delete); } static void usbtmc_draw_down(struct usbtmc_file_data *file_data) -- 2.25.1
Re: [PATCH v6 05/14] dt-bindings: display: bridge: Add i.MX8qm/qxp display pixel link binding
Hi Marcel,
On Tue, 2021-03-23 at 00:38 +, Marcel Ziswiler wrote:
> On Wed, 2021-03-17 at 11:42 +0800, Liu Ying wrote:
> > This patch adds bindings for i.MX8qm/qxp display pixel link.
> >
> > Reviewed-by: Rob Herring
> > Signed-off-by: Liu Ying
> > ---
> > v5->v6:
> > * No change.
> >
> > v4->v5:
> > * No change.
> >
> > v3->v4:
> > * No change.
> >
> > v2->v3:
> > * Add Rob's R-b tag.
> >
> > v1->v2:
> > * Use graph schema. (Laurent)
> > * Require all four pixel link output ports. (Laurent)
> > * Mention pixel link is accessed via SCU firmware. (Rob)
> >
> > .../display/bridge/fsl,imx8qxp-pixel-link.yaml | 106
> > +
> > 1 file changed, 106 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml
> > b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml
> > new file mode 100644
> > index ..3af67cc
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml
> > @@ -0,0 +1,106 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id:
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fschemas%2Fdisplay%2Fbridge%2Ffsl%2Cimx8qxp-pixel-link.yaml%23data=04%7C01%7Cvictor.liu%40nxp.com%7C281077e1c1324aa89ad008d8ed93f1f0%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637520566973165920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=2NDRsaWJ6YGFg%2FWAjT1Yf9Y0OaRDSHG0fWghi9UKNRA%3Dreserved=0
> > +$schema:
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23data=04%7C01%7Cvictor.liu%40nxp.com%7C281077e1c1324aa89ad008d8ed93f1f0%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637520566973165920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ogBn2bQmj1YwDqg0KDMXZ%2FwL0VkdOA14n5ayBioMcos%3Dreserved=0
> > +
> > +title: Freescale i.MX8qm/qxp Display Pixel Link
> > +
> > +maintainers:
> > + - Liu Ying
> > +
> > +description: |
> > + The Freescale i.MX8qm/qxp Display Pixel Link(DPL) forms a standard
> > + asynchronous linkage between pixel sources(display controller or
> > + camera module) and pixel consumers(imaging or displays).
> > + It consists of two distinct functions, a pixel transfer function and a
> > + control interface. Multiple pixel channels can exist per one control
> > channel.
> > + This binding documentation is only for pixel links whose pixel sources
> > are
> > + display controllers.
> > +
> > + The i.MX8qm/qxp Display Pixel Link is accessed via System Controller
> > Unit(SCU)
> > + firmware.
> > +
> > +properties:
> > + compatible:
> > +enum:
> > + - fsl,imx8qm-dc-pixel-link
> > + - fsl,imx8qxp-dc-pixel-link
> > +
> > + ports:
> > +$ref: /schemas/graph.yaml#/properties/ports
> > +
> > +properties:
> > + port@0:
> > +$ref: /schemas/graph.yaml#/properties/port
> > +description: The pixel link input port node from upstream video
> > source.
> > +
> > +patternProperties:
> > + "^port@[1-4]$":
> > +$ref: /schemas/graph.yaml#/properties/port
> > +description: The pixel link output port node to downstream bridge.
> > +
> > +required:
> > + - port@0
> > + - port@1
> > + - port@2
> > + - port@3
> > + - port@4
> > +
> > +required:
> > + - compatible
> > + - ports
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +dc0-pixel-link0 {
> > +compatible = "fsl,imx8qxp-dc-pixel-link";
> > +
> > +ports {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +/* from dc0 pixel combiner channel0 */
> > +port@0 {
> > +reg = <0>;
> > +
> > +dc0_pixel_link0_dc0_pixel_combiner_ch0: endpoint {
> > +remote-endpoint =
> > <_pixel_combiner_ch0_dc0_pixel_link0>;
> > +};
> > +};
> > +
> > +/* to PXL2DPIs in MIPI/LVDS combo subsystems */
> > +port@1 {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +reg = <1>;
> > +
> > +dc0_pixel_link0_mipi_lvds_0_pxl2dpi: endpoint@0 {
> > +reg = <0>;
> > +remote-endpoint =
> > <_lvds_0_pxl2dpi_dc0_pixel_link0>;
> > +};
> > +
> > +dc0_pixel_link0_mipi_lvds_1_pxl2dpi: endpoint@1 {
> > +reg = <1>;
> > +remote-endpoint =
> > <_lvds_1_pxl2dpi_dc0_pixel_link0>;
>
> Those also seem absent from other examples.
Patch 8/14 adds dt-binding for PXL2DPI. An example for the PXL2DPI
instance
[PATCH] tools: testing: inttypes.h is included twice
inttypes.h has been included at line 19. So we remove the duplicate one at line 23. Signed-off-by: Wan Jiabing --- tools/testing/selftests/powerpc/tm/tm-poison.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/testing/selftests/powerpc/tm/tm-poison.c b/tools/testing/selftests/powerpc/tm/tm-poison.c index 29e5f26af7b9..27c083a03d1f 100644 --- a/tools/testing/selftests/powerpc/tm/tm-poison.c +++ b/tools/testing/selftests/powerpc/tm/tm-poison.c @@ -20,7 +20,6 @@ #include #include #include -#include #include "tm.h" -- 2.25.1
[PATCH] tools: testing: pthread.h is included twice
pthread.h has been included at line 17. So we remove the duplicate one at line 20. Signed-off-by: Wan Jiabing --- tools/testing/selftests/powerpc/tm/tm-vmx-unavail.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/testing/selftests/powerpc/tm/tm-vmx-unavail.c b/tools/testing/selftests/powerpc/tm/tm-vmx-unavail.c index e2a0c07e8362..9ef37a9836ac 100644 --- a/tools/testing/selftests/powerpc/tm/tm-vmx-unavail.c +++ b/tools/testing/selftests/powerpc/tm/tm-vmx-unavail.c @@ -17,7 +17,6 @@ #include #include #include -#include #include "tm.h" #include "utils.h" -- 2.25.1
Re: [PATCH 8/9] arm64: dts: qcom: sc7280: Add AOSS QMP node
Quoting Sibi Sankar (2021-03-08 21:58:21)
> On 2021-02-27 19:26, Sai Prakash Ranjan wrote:
> > On 2021-02-27 00:16, Stephen Boyd wrote:
> >> Quoting Sai Prakash Ranjan (2021-02-25 23:51:00)
> >>> On 2021-02-26 01:11, Stephen Boyd wrote:
> >>> > Quoting Sai Prakash Ranjan (2021-02-25 01:30:24)
> >>> >> Add a DT node for the AOSS QMP on SC7280 SoC.
> >>> >>
> >>> >> Signed-off-by: Sai Prakash Ranjan
> >>> >> ---
> >>> >> arch/arm64/boot/dts/qcom/sc7280.dtsi | 14 ++
> >>> >> 1 file changed, 14 insertions(+)
> >>> >>
> >>> >> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> >>> >> b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> >>> >> index 65c1e0f2fb56..cbd567ccc04e 100644
> >>> >> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> >>> >> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> >>> >> @@ -9,6 +9,7 @@
> >>> >> #include
> >>> >> #include
> >>> >> #include
> >>> >> +#include
> >>> >> #include
> >>> >>
> >>> >> / {
> >>> >> @@ -368,6 +369,19 @@ pdc: interrupt-controller@b22 {
> >>> >> interrupt-controller;
> >>> >> };
> >>> >>
> >>> >> + aoss_qmp: qmp@c30 {
> >>> >
> >>> > power-domain-controller@c30? power-controller@c30?
> >>> >
> >>>
> >>> Its an AOSS message RAM and all other SM* SoCs have as qmp@
> >>> and the dt binding as well, I see only SM8150 with power-controller,
> >>> that should probably be fixed?
> >>
> >> Node name should be generic while still being meaningful. Nobody knows
> >> what qmp is, but power-controller makes sense. Can you fix this and
> >> the
> >> others to be power-controller?
> >>
>
> we probably would be changing them back
> to qmp or something more generic soon
> since the consensus was qmp wasn't a
> power-controller. So not sure if its
> worth the effort here.
>
Hmm alright. Maybe mailbox? qmp is not generic. What does it stand for?
qualcomm messaging protocol?
Re: [PATCH 6/6] firmware: qcom_scm: Only compile legacy calls on ARM
Quoting Bjorn Andersson (2021-03-07 09:42:45) > On Sat 06 Mar 00:18 CST 2021, Stephen Boyd wrote: > > > Quoting Elliot Berman (2021-03-05 10:18:09) > > > On 3/3/2021 10:14 PM, Stephen Boyd wrote: > > > > Quoting Elliot Berman (2021-03-03 19:35:08) > > > > > > > +desc.args[0] = flags; > > > > +desc.args[1] = virt_to_phys(entry); > > > > + > > > > +return scm_legacy_call_atomic(NULL, , NULL); > > > > +} > > > > +EXPORT_SYMBOL(qcom_scm_set_cold_boot_addr); > > > > > > This should still be qcom_scm_call. > > > > You mean s/scm_legacy_call_atomic/qcom_scm_call/ right? > > > > I don't really want to resend the rest of the patches if this last one > > is the only one that needs an update. This was a semi-RFC anyway so > > maybe it's fine if the first 5 patches get merged and then I can resend > > this one? Otherwise I will resend this again next week or so with less > > diff for this patch. > > I'm fine with merging the first 5, but was hoping that Elliot could > provide either a "Reviewed-by" or at least an "Acked-by" on these. > I'll take the silence as I should resend the whole series?
Re: [EXTERNAL]Re: [PATCH 0/5] Remove dead linux-mips.org references
This message was rejected by the spam filter at vger.kernel.org. To ensure that everybody on the original email list gets the reply, I'm resending it as plain text (which I should have figured out long ago). I profusely apologize for the multiple resends. Hi Lukas, I apologize for the delay. As you may know, we recently emerged from Chapter 11 reorganization and I'm working on a lot of issues related to this. I did get in touch with Ralf, but I have not been able to make progress with Hetzner. I'm dependent on Ralf to help me get the machine at Hetzner working again. I will continue to try to do this. If waiting for me to get linux-mips.org working is not an option, I understand that you may have to move on. I know the disappearance of linux-mips.org has caused problems for you. But can you please help me understand the implication of your question: "should Thomas pick up the remaining patches of this series?" I am thinking the answer to that question is yes, but I'm not sure if I'm the right person to answer that question. I guess I am somewhat clueless about how the patch process works for MIPS, and how linux-mips.org is involved. If I am never able to get linux-mips.org back online, what does that mean? So please understand that I want to keep the "MIPS infrastructure" items such as linux-mips.org functioning. Any help or suggestions are welcomed. Thank you. Regards, Kurt From: Lukas Bulwahn Sent: Monday, March 22, 2021 12:52 AM To: Kurt Martin Cc: Maciej W. Rozycki ; Thomas Bogendoerfer ; linux-m...@vger.kernel.org ; Tiezhu Yang ; Willy Tarreau ; linux-e...@vger.kernel.org ; linux-h...@vger.kernel.org ; kernel-janit...@vger.kernel.org ; linux-kernel@vger.kernel.org Subject: Re: [EXTERNAL]Re: [PATCH 0/5] Remove dead linux-mips.org references On Mon, Feb 22, 2021 at 7:19 PM Kurt Martin wrote: > > Hi Everybody, > > This is Kurt Martin. I'm part of the MIPS Customer Engineering team at Wave > Computing. Some of you may remember me. I have just established contact > with Ralf, and I will be working with him to restore linux-mips.org back to > life. I just got the account and login information for the linux-mips.org > hosting account at Hetzner from Chris Dearman. > > So as Maciej says, please hold off any actions at this time, and I will > attempt to get linux-mips.org working again as quickly as possible. Thanks! > It has been a month by now... I just wanted to check if linux-mips.org is back on its way to be available. Or should Thomas pick up the remaining patches of this series? Lukas
Re: [PATCH] sched: Warn on long periods of pending need_resched
On Fri, Mar 19, 2021 at 2:02 AM Mel Gorman wrote: > > Default disabling and hidden behind a static branch would be useful > because the majority of users are not going to know what to do about > a need_resched warning and the sysctl is not documented. As Ingo said, > SCHED_DEBUG is enabled by default a lot. While I'm not sure what motivates > most distributions, I have found it useful to display topology information > on boot and in rare cases, for the enabling/disabling of sched features. > Hence, sched debug features should avoid adding too much overhead where > possible. > > The static branch would mean splitting the very large inline functions > adding by the patch. The inline section should do a static check only and > do the main work in a function in kernel/sched/debug.c so it has minimal > overhead if unused. > > -- > Mel Gorman > SUSE Labs Makes sense, I'll include this in v2. Thanks, Josh
[PATCH] tools: testing: Remove duplicate include of sched.h
sched.h has been included at line 33. So we remove the duplicate one at line 36. Signed-off-by: Wan Jiabing --- tools/testing/selftests/powerpc/mm/tlbie_test.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/testing/selftests/powerpc/mm/tlbie_test.c b/tools/testing/selftests/powerpc/mm/tlbie_test.c index f85a0938ab25..48344a74b212 100644 --- a/tools/testing/selftests/powerpc/mm/tlbie_test.c +++ b/tools/testing/selftests/powerpc/mm/tlbie_test.c @@ -33,7 +33,6 @@ #include #include #include -#include #include #include #include -- 2.25.1
Re: [PATCH V1 1/1] soc: qcom: smp2p: Add enable_irq_wake to SMP2P IRQ
Quoting Deepak Kumar Singh (2021-03-18 11:37:04) > SMP2P interrupts are expected to wake the processor from suspend. > Use enable_irq_wake to mark it wakeup capable from suspend. > > Signed-off-by: Chris Lew > Signed-off-by: Deepak Kumar Singh > --- > drivers/soc/qcom/smp2p.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/soc/qcom/smp2p.c b/drivers/soc/qcom/smp2p.c > index 2df4883..df47ee6 100644 > --- a/drivers/soc/qcom/smp2p.c > +++ b/drivers/soc/qcom/smp2p.c > @@ -538,6 +538,7 @@ static int qcom_smp2p_probe(struct platform_device *pdev) > goto unwind_interfaces; > } > > + enable_irq_wake(irq); > Can this use device_init_wakeup() and dev_pm_set_wake_irq() instead? I think that will help us recognize that this irq woke up the CPU and allow userspace to indicate that it doesn't want to get this wakeup for some reason. > return 0; >
Re: [PATCH v6 03/14] dt-bindings: display: bridge: Add i.MX8qm/qxp pixel combiner binding
Hi Marcel,
On Tue, 2021-03-23 at 00:34 +, Marcel Ziswiler wrote:
> On Wed, 2021-03-17 at 11:42 +0800, Liu Ying wrote:
> > This patch adds bindings for i.MX8qm/qxp pixel combiner.
> >
> > Reviewed-by: Rob Herring
> > Signed-off-by: Liu Ying
> > ---
> > v5->v6:
> > * No change.
> >
> > v4->v5:
> > * No change.
> >
> > v3->v4:
> > * No change.
> >
> > v2->v3:
> > * Add Rob's R-b tag.
> >
> > v1->v2:
> > * Use graph schema. (Laurent)
> > * Use enum instead of oneOf + const for the reg property of pixel combiner
> > channels. (Rob)
> >
> > .../display/bridge/fsl,imx8qxp-pixel-combiner.yaml | 144
> > +
> > 1 file changed, 144 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml
> > b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml
> > new file mode 100644
> > index ..50bae21
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml
> > @@ -0,0 +1,144 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id:
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fschemas%2Fdisplay%2Fbridge%2Ffsl%2Cimx8qxp-pixel-combiner.yaml%23data=04%7C01%7Cvictor.liu%40nxp.com%7Cb83106f0261d4f715b4208d8ed936cb1%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637520564736692120%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=%2B4sZ3C9r3cewzQ01YHOvGk%2FCZaqQgg3ALftZ1dPLKIE%3Dreserved=0
> > +$schema:
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23data=04%7C01%7Cvictor.liu%40nxp.com%7Cb83106f0261d4f715b4208d8ed936cb1%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637520564736692120%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=sP82pZYZXLKhzRRoYPR4C%2FFsDLUka1Fj0%2FA9InuWuvg%3Dreserved=0
> > +
> > +title: Freescale i.MX8qm/qxp Pixel Combiner
> > +
> > +maintainers:
> > + - Liu Ying
> > +
> > +description: |
> > + The Freescale i.MX8qm/qxp Pixel Combiner takes two output streams from a
> > + single display controller and manipulates the two streams to support a
> > number
> > + of modes(bypass, pixel combine, YUV444 to YUV422, split_RGB) configured
> > as
> > + either one screen, two screens, or virtual screens. The pixel combiner
> > is
> > + also responsible for generating some of the control signals for the
> > pixel link
> > + output channel.
> > +
> > +properties:
> > + compatible:
> > +enum:
> > + - fsl,imx8qm-pixel-combiner
> > + - fsl,imx8qxp-pixel-combiner
> > +
> > + "#address-cells":
> > +const: 1
> > +
> > + "#size-cells":
> > +const: 0
> > +
> > + reg:
> > +maxItems: 1
> > +
> > + clocks:
> > +maxItems: 1
> > +
> > + clock-names:
> > +const: apb
> > +
> > + power-domains:
> > +maxItems: 1
> > +
> > +patternProperties:
> > + "^channel@[0-1]$":
> > +type: object
> > +description: Represents a display stream of pixel combiner.
> > +
> > +properties:
> > + "#address-cells":
> > +const: 1
> > +
> > + "#size-cells":
> > +const: 0
> > +
> > + reg:
> > +description: The display stream index.
> > +enum: [ 0, 1 ]
> > +
> > + port@0:
> > +$ref: /schemas/graph.yaml#/properties/port
> > +description: Input endpoint of the display stream.
> > +
> > + port@1:
> > +$ref: /schemas/graph.yaml#/properties/port
> > +description: Output endpoint of the display stream.
> > +
> > +required:
> > + - "#address-cells"
> > + - "#size-cells"
> > + - reg
> > + - port@0
> > + - port@1
> > +
> > +additionalProperties: false
> > +
> > +required:
> > + - compatible
> > + - "#address-cells"
> > + - "#size-cells"
> > + - reg
> > + - clocks
> > + - clock-names
> > + - power-domains
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +#include
> > +pixel-combiner@5602 {
> > +compatible = "fsl,imx8qxp-pixel-combiner";
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +reg = <0x5602 0x1>;
> > +clocks = <_pixel_combiner_lpcg IMX_LPCG_CLK_4>;
> > +clock-names = "apb";
> > +power-domains = < IMX_SC_R_DC_0>;
> > +
> > +channel@0 {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +reg = <0>;
> > +
> > +port@0 {
> > +reg = <0>;
> > +
> > +dc0_pixel_combiner_ch0_dc0_dpu_disp0: endpoint {
> > +remote-endpoint =
> > <_dpu_disp0_dc0_pixel_combiner_ch0>;
>
> While I acknowledge this just
[PATCH] tools: testing: Remove duplicate include of string.h
string.h has been included at line 15.So we remove the duplicate one at line 17. Signed-off-by: Wan Jiabing --- tools/testing/selftests/mincore/mincore_selftest.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/testing/selftests/mincore/mincore_selftest.c b/tools/testing/selftests/mincore/mincore_selftest.c index 5a1e85ff5d32..e54106643337 100644 --- a/tools/testing/selftests/mincore/mincore_selftest.c +++ b/tools/testing/selftests/mincore/mincore_selftest.c @@ -14,7 +14,6 @@ #include #include #include -#include #include "../kselftest.h" #include "../kselftest_harness.h" -- 2.25.1
[PATCH 4/4] rust: Enable for ppc64le
All the pieces are in place now for us to enable building rust support on ppc64le. Only works with clang for now. Signed-off-by: Michael Ellerman --- init/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/init/Kconfig b/init/Kconfig index d73ac9de186d..ddc2fda1a22c 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -58,7 +58,7 @@ config LLD_VERSION default 0 config HAS_RUST - depends on ARM64 || X86_64 + depends on ARM64 || X86_64 || (PPC64 && CPU_LITTLE_ENDIAN && CC_IS_CLANG) def_bool $(success,$(RUSTC) --version) config RUSTC_VERSION -- 2.25.1
[PATCH 3/4] powerpc/rust: Add target.json for ppc64le
Based on the x86 and arm64 versions, as well as output from:
$ rustc +nightly -Z unstable-options --target=powerpc64le-unknown-linux-gnu
--print target-spec-json
Notably disables altivec, vsx and hard-float.
The very cryptic data-layout:
"data-layout": "e-m:e-i64:64-n32:64-S128",
Has the following meaning:
e: little endian
m:eELF name mangling
i64:64 64-bit integers 64-bit aligned
n32:64 Native integer widths, 32-bit and 64-bit.
S128 16-byte stack alignment
Those all come from the rustc output, with the exception of the stack
alignment. We obviously do have 8-bit & 16-bit integer types, but I'm
not sure if there's any need to specify that.
ppc64le only for now. We'll eventually need to come up with some way to
change the target.json that's used based on more than just $(ARCH).
Signed-off-by: Michael Ellerman
---
arch/powerpc/rust/target.json | 30 ++
1 file changed, 30 insertions(+)
create mode 100644 arch/powerpc/rust/target.json
diff --git a/arch/powerpc/rust/target.json b/arch/powerpc/rust/target.json
new file mode 100644
index ..1e53f8308092
--- /dev/null
+++ b/arch/powerpc/rust/target.json
@@ -0,0 +1,30 @@
+{
+ "arch": "powerpc64",
+ "code-mode": "kernel",
+ "cpu": "ppc64le",
+ "data-layout": "e-m:e-i64:64-n32:64",
+ "env": "gnu",
+ "features": "-altivec,-vsx,-hard-float",
+ "function-sections": false,
+ "is-builtin": true,
+ "linker-flavor": "gcc",
+ "linker-is-gnu": true,
+ "llvm-target": "powerpc64le-elf",
+ "max-atomic-width": 64,
+ "os": "none",
+ "panic-strategy": "abort",
+ "position-independent-executables": true,
+ "pre-link-args": {
+"gcc": [
+ "-Wl,--as-needed",
+ "-Wl,-z,noexecstack",
+ "-m64"
+]
+ },
+ "relocation-model": "static",
+ "relro-level": "full",
+ "target-family": "unix",
+ "target-mcount": "_mcount",
+ "target-endian": "little",
+ "target-pointer-width": "64"
+}
--
2.25.1
[PATCH 1/4] rust: Export symbols in initialized data section
On powerpc some symbols end up in the initialized data section, which means they aren't detected by the logic in cmd_export, leading to errors such as: ERROR: modpost: "_RNvNtCsbDqzXfLQacH_6kernel12module_param15PARAM_OPS_USIZE" [drivers/char/rust_example_4.ko] undefined! nm represents the "initialized data section" with "D", so also look for that when exporting symbols. Signed-off-by: Michael Ellerman --- rust/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rust/Makefile b/rust/Makefile index eb8f12ce1644..4cddae9d4a25 100644 --- a/rust/Makefile +++ b/rust/Makefile @@ -73,7 +73,7 @@ $(objtree)/rust/bindings_generated.rs: $(srctree)/rust/kernel/bindings_helper.h quiet_cmd_exports = EXPORTS $@ cmd_exports = \ $(NM) -p --defined-only $< \ - | grep -E ' (T|R) ' | cut -d ' ' -f 3 | grep -E '^(__rust_|_R)' \ + | grep -E ' (T|R|D) ' | cut -d ' ' -f 3 | grep -E '^(__rust_|_R)' \ | xargs -n1 -Isymbol \ echo 'EXPORT_SYMBOL$(exports_target_type)(symbol);' > $@ -- 2.25.1
[PATCH 2/4] rust: Add powerpc64 as a 64-bit target_arch in c_types.rs
powerpc kernel code uses int-ll64.h.
Signed-off-by: Michael Ellerman
---
rust/kernel/c_types.rs | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rust/kernel/c_types.rs b/rust/kernel/c_types.rs
index 423ac1108ddb..988fd84b0d66 100644
--- a/rust/kernel/c_types.rs
+++ b/rust/kernel/c_types.rs
@@ -60,7 +60,7 @@ mod c {
pub type c_size_t = usize;
}
-#[cfg(any(target_arch = "aarch64", target_arch = "x86_64"))]
+#[cfg(any(target_arch = "aarch64", target_arch = "x86_64", target_arch =
"powerpc64"))]
mod c {
/// C `void` type.
pub type c_void = core::ffi::c_void;
--
2.25.1
[PATCH 0/4] Rust for Linux for ppc64le
Hi all, Here's a first attempt at getting the kernel Rust support building on powerpc. It's powerpc64le only for now, as that's what I can easily test given the distros I have installed. Though powerpc and powerpc64 are also Tier 2 platforms so in theory should work. Supporting those would require something more complicated than just pointing rustc at arch/$(ARCH)/rust/target.json. This is based on 832575d934a2 from the Rust-for-Linux tree. Anything newer gives me errors about symbol name lengths. I figured I'd send this anyway, as it seems like those errors are probably not powerpc specific. I'm not sure that all the values in target.json are correct, or required (or if any are missing), but what I have there seems to work. Would be happy for someone to scrutinise it though. Example output: # uname -r 5.12.0-rc3-47689-ge4e12dd7cb75 # uname -m ppc64le # modprobe rust_example Rust Example (init) Am I built-in? false Parameters: my_bool:true my_i32: 42 my_str: default str val my_usize: 42 my_array: [0, 1] Value: 10 Value: 10 Large array has length: 514 modprobe (1589) used greatest stack depth: 6800 bytes left # modprobe rust_example_2 [2] Rust Example (init) [2] Am I built-in? false [2] Parameters: [2] my_bool:true [2] my_i32: 42 [2] my_str: default str val [2] my_usize: 42 [2] my_array: [0, 1] Large array has length: 1028 modprobe (1593) used greatest stack depth: 3680 bytes left # modprobe rust_example_3 [3] Rust Example (init) [3] Am I built-in? false [3] Parameters: [3] my_bool:true [3] my_i32: 42 [3] my_str: default str val [3] my_usize: 42 [3] my_array: [0, 1] Large array has length: 1028 # modprobe rust_example_4 [4] Rust Example (init) [4] Am I built-in? false [4] Parameters: [4] my_bool:true [4] my_i32: 42 [4] my_str: default str val [4] my_usize: 42 [4] my_array: [0, 1] Large array has length: 1028 cheers Michael Ellerman (4): rust: Export symbols in initialized data section rust: Add powerpc64 as a 64-bit target_arch in c_types.rs powerpc/rust: Add target.json for ppc64le rust: Enable for ppc64le arch/powerpc/rust/target.json | 30 ++ init/Kconfig | 2 +- rust/Makefile | 2 +- rust/kernel/c_types.rs| 2 +- 4 files changed, 33 insertions(+), 3 deletions(-) create mode 100644 arch/powerpc/rust/target.json base-commit: 832575d934a2bc5e2fd0aa881d8e6b64bf062fd2 -- 2.25.1
Re: [PATCH V2 0/6] PM / devfreq: a few small fixes and improvements
Hi Chanwoo, On Tue, Mar 23, 2021 at 11:13 AM Dong Aisheng wrote: > > A few small fixes and improvements > > ChangeLog: > v1->v2: > * squash a few patches > * rebase to devfreq-testing I have to rebase to devfreq-testing instead of devfreq-next because below two patches only exist in devfreq-testing. 5cc75e9252e9 (devfreq/devfreq-testing) PM / devfreq: Add devfreq_transitions debugfs file dc9e557845c1 PM / devfreq: Add new up_threshold and down_differential sysfs attrs My patch 5 needs change based on it according to your suggestion. So i have to rebase to that branch. However, i found devfreq-testing can't build with GOV_PASSVIE enabled. Patch 1 fixed it. You can squash to the original one when apply. Please help take a look at this new series. Thanks Regards Aisheng > * drop two patches which are already in devfreq-next > > Dong Aisheng (6): > PM / devfreq: fix build error when DEVFREQ_GOV_PASSIVE enabled > PM / devfreq: Use more accurate returned new_freq as resume_freq > PM / devfreq: Remove the invalid description for get_target_freq > PM / devfreq: bail out early if no freq changes in devfreq_set_target > PM / devfreq: governor: optimize simpleondemand get_target_freq > PM / devfreq: imx8m-ddrc: remove imx8m_ddrc_get_dev_status > > Documentation/ABI/testing/sysfs-class-devfreq | 5 +-- > drivers/devfreq/devfreq.c | 37 +++ > drivers/devfreq/governor.h| 2 - > drivers/devfreq/governor_simpleondemand.c | 31 ++-- > drivers/devfreq/imx8m-ddrc.c | 14 --- > 5 files changed, 35 insertions(+), 54 deletions(-) > > -- > 2.25.1 >
Re: [PATCH] drm/msm/dp: Fixed couple of typos
Quoting Bhaskar Chowdhury (2021-03-17 23:26:50) > s/modueles/modules/ two different places > > Signed-off-by: Bhaskar Chowdhury > --- Reviewed-by: Stephen Boyd
[PATCH] mm: process_vm_access: Remove duplicate include of compat.h
linux/compat.h has been included at line 8.So we remove the duplicate one at line 12. Signed-off-by: Wan Jiabing --- mm/process_vm_access.c | 1 - 1 file changed, 1 deletion(-) diff --git a/mm/process_vm_access.c b/mm/process_vm_access.c index f5fee9cf90f8..4bcc11958089 100644 --- a/mm/process_vm_access.c +++ b/mm/process_vm_access.c @@ -9,7 +9,6 @@ #include #include #include -#include #include #include #include -- 2.25.1
Re: [PATCH bpf-next 2/5] bpf: Add a bpf_snprintf helper
On Wed, Mar 10, 2021 at 11:02:08PM +0100, Florent Revest wrote:
>
> +struct bpf_snprintf_buf {
> + char buf[MAX_SNPRINTF_MEMCPY][MAX_SNPRINTF_STR_LEN];
> +};
> +static DEFINE_PER_CPU(struct bpf_snprintf_buf, bpf_snprintf_buf);
> +static DEFINE_PER_CPU(int, bpf_snprintf_buf_used);
> +
> +BPF_CALL_5(bpf_snprintf, char *, out, u32, out_size, char *, fmt, u64 *,
> args,
> +u32, args_len)
> +{
> + int err, i, buf_used, copy_size, fmt_cnt = 0, memcpy_cnt = 0;
> + u64 params[MAX_SNPRINTF_VARARGS];
> + struct bpf_snprintf_buf *bufs;
> +
> + buf_used = this_cpu_inc_return(bpf_snprintf_buf_used);
> + if (WARN_ON_ONCE(buf_used > 1)) {
this can trigger only if the helper itself gets preempted and
another bpf prog will run on the same cpu and will call into this helper
again, right?
If so, how about adding preempt_disable here to avoid this case?
It won't prevent the case where kprobe is inside snprintf core,
so the counter is still needed, but it wouldn't trigger by accident.
Also since bufs are not used always, how about grabbing the
buffers only when %p or %s are seen in fmt?
After snprintf() is done it would conditionally do:
if (bufs_were_used) {
this_cpu_dec(bpf_snprintf_buf_used);
preempt_enable();
}
This way simple bpf_snprintf won't ever hit EBUSY.
> + err = -EBUSY;
> + goto out;
> + }
> +
> + bufs = this_cpu_ptr(_snprintf_buf);
> +
> + /*
> + * The verifier has already done most of the heavy-work for us in
> + * check_bpf_snprintf_call. We know that fmt is well formatted and that
> + * args_len is valid. The only task left is to convert some of the
> + * arguments. For the %s and %pi* specifiers, we need to read buffers
> + * from a kernel address during the helper call.
> + */
> + for (i = 0; fmt[i] != '\0'; i++) {
> + if (fmt[i] != '%')
> + continue;
> +
> + if (fmt[i + 1] == '%') {
> + i++;
> + continue;
> + }
> +
> + /* fmt[i] != 0 && fmt[last] == 0, so we can access fmt[i + 1] */
> + i++;
> +
> + /* skip optional "[0 +-][num]" width formating field */
> + while (fmt[i] == '0' || fmt[i] == '+' || fmt[i] == '-' ||
> +fmt[i] == ' ')
> + i++;
> + if (fmt[i] >= '1' && fmt[i] <= '9') {
> + i++;
> + while (fmt[i] >= '0' && fmt[i] <= '9')
> + i++;
> + }
> +
> + if (fmt[i] == 's') {
> + void *unsafe_ptr = (void *)(long)args[fmt_cnt];
> +
> + err = strncpy_from_kernel_nofault(bufs->buf[memcpy_cnt],
> + unsafe_ptr,
> + MAX_SNPRINTF_STR_LEN);
> + if (err < 0)
> + bufs->buf[memcpy_cnt][0] = '\0';
> + params[fmt_cnt] = (u64)(long)bufs->buf[memcpy_cnt];
how about:
char buf[512]; instead?
instead of memcpy_cnt++ remember how many bytes of the buf were used and
copy next arg after that.
The scratch space would be used more efficiently.
The helper would potentially return ENOSPC if the first string printed via %s
consumed most of the 512 space and the second string doesn't fit.
But the verifier-time if (memcpy_cnt >= MAX_SNPRINTF_MEMCPY) can be removed.
Ten small %s will work fine.
We can allocate a page per-cpu when this helper is used by prog and free
that page when all progs with bpf_snprintf are unloaded.
But extra complexity is probably not worth it. I would start with 512 per-cpu.
It's going to be enough for most users.
Overall looks great. Cannot wait for v2 :)
[PATCH] include: linux: mtd: Remove duplicate include of nand.h
linux/mtd/nand.h has been included at line 17. So we remove the duplicate one at line 21. Signed-off-by: Wan Jiabing --- include/linux/mtd/rawnand.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h index 6b3240e44310..93e8f72beba6 100644 --- a/include/linux/mtd/rawnand.h +++ b/include/linux/mtd/rawnand.h @@ -18,7 +18,6 @@ #include #include #include -#include #include #include #include -- 2.25.1
Re: [PATCH v3 3/4] drm/bridge: ti-sn65dsi86: Read EDID blob over DDC
Quoting Laurent Pinchart (2021-03-17 17:20:43)
> Hi Stephen,
>
> Reviving a bit of an old thread, for a question.
>
> On Mon, Nov 02, 2020 at 10:11:43AM -0800, Stephen Boyd wrote:
> > @@ -265,6 +267,23 @@ connector_to_ti_sn_bridge(struct drm_connector
> > *connector)
> > static int ti_sn_bridge_connector_get_modes(struct drm_connector
> > *connector)
> > {
> > struct ti_sn_bridge *pdata = connector_to_ti_sn_bridge(connector);
> > + struct edid *edid = pdata->edid;
> > + int num, ret;
> > +
> > + if (!edid) {
> > + pm_runtime_get_sync(pdata->dev);
> > + edid = pdata->edid = drm_get_edid(connector, >aux.ddc);
> > + pm_runtime_put(pdata->dev);
>
> Is there any specific reason to use the indirect access method, compared
> to the direct method that translates access to an I2C ancillary address
> to an I2C-over-AUX transaction (see page 20 of SLLSEH2B) ? The direct
> method seems it would be more efficient.
>
No I don't think it matters. I was just using the existing support code
that Sean wrote instead of digging into the details. Maybe Sean ran into
something earlier and abandoned that approach?
Re: [PATCH] KVM: VMX: Check the corresponding bits according to the intel sdm
On Mon, Mar 22, 2021 at 7:37 PM wrote: > > From: Haiwei Li > > According to IA-32 SDM Vol.3D "A.1 BASIC VMX INFORMATION", two inspections > are missing. > * Bit 31 is always 0. Earlier versions of this manual specified that the > VMCS revision identifier was a 32-bit field in bits 31:0 of this MSR. For > all processors produced prior to this change, bit 31 of this MSR was read > as 0. For all *Intel* processors produced prior to this change, bit 31 of this MSR may have been 0. However, a conforming hypervisor may have selected a full 32-bit VMCS revision identifier with the high bit set for nested VMX. Furthermore, there are other vendors, such as VIA, which have implemented the VMX extensions, and they, too, may have selected a full 32-bit VMCS revision identifier with the high bit set. Intel should know better than to change the documentation after the horse is out of the barn. What, exactly, is the value you are adding with this check?
RE: [PATCH 1/5] cifsd: add server handler and tranport layers
> On Tue, Mar 23, 2021 at 12:01:22PM +0900, Namjae Jeon wrote: > > > On Mon, Mar 22, 2021 at 02:13:40PM +0900, Namjae Jeon wrote: > > > > +#define RESPONSE_BUF(w)((void *)(w)->response_buf) > > > > +#define REQUEST_BUF(w) ((void *)(w)->request_buf) > > > > > > Why do you do this obfuscation? > > I don't remember exactly, but back then, It looked easier... > > > > > > > +#define RESPONSE_BUF_NEXT(w) \ > > > > + ((void *)((w)->response_buf + (w)->next_smb2_rsp_hdr_off)) > > > > +#define REQUEST_BUF_NEXT(w)\ > > > > + ((void *)((w)->request_buf + (w)->next_smb2_rcv_hdr_off)) > > > > > > These obfuscations aren't even used; delete them > > They are used in many place. > > Oh, argh. patch 2/5 was too big, so it didn't make it into the mailing list > archive I was using to > try to review this series. Please break it up into smaller pieces for next > time! Okay:) Thanks!
[PATCH] thunderbolt: Fix a double put in tb_cfg_read_raw
In tb_cfg_read_raw, req is allocated by tb_cfg_request_alloc() with an initial reference. Before calling tb_cfg_request_sync(), there is no refcount inc operation. tb_cfg_request_sync() calls tb_cfg_request(..,req,..) and if the callee failed, the initial reference of req is dropped and req is freed. Later in tb_cfg_read_raw before the err check, tb_cfg_request_put(req) is called again. It may cause error in race. My patch puts tb_cfg_request_put(req) after the err check finished to avoid unexpected result. Signed-off-by: Lv Yunlong --- drivers/thunderbolt/ctl.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/thunderbolt/ctl.c b/drivers/thunderbolt/ctl.c index f1aeaff9f368..bb60269c89ab 100644 --- a/drivers/thunderbolt/ctl.c +++ b/drivers/thunderbolt/ctl.c @@ -890,11 +890,11 @@ struct tb_cfg_result tb_cfg_read_raw(struct tb_ctl *ctl, void *buffer, res = tb_cfg_request_sync(ctl, req, timeout_msec); - tb_cfg_request_put(req); - if (res.err != -ETIMEDOUT) break; + tb_cfg_request_put(req); + /* Wait a bit (arbitrary time) until we send a retry */ usleep_range(10, 100); } -- 2.25.1
Re: [PATCH] arm64: dts: qcom: sc7180: Fix sc7180-qmp-usb3-dp-phy reg sizes
Quoting Douglas Anderson (2021-03-15 10:38:54)
> As per Dmitry Baryshkov [1]:
> a) The 2nd "reg" should be 0x3c because "Offset 0x38 is
>USB3_DP_COM_REVISION_ID3 (not used by the current driver though)."
I see 0x34 for the offset here instead of 0x38 but I don't think it
really matters either way.
> b) The 3rd "reg" "is a serdes region and qmp_v3_dp_serdes_tbl contains
>registers 0x148 and 0x154."
>
> I think because the 3rd "reg" is a serdes region we should just use
> the same size as the 1st "reg"?
>
> [1] https://lore.kernel.org/r/ee5695bb-a603-0dd5-7a7f-695e919b1...@linaro.org
>
> Cc: Stephen Boyd
> Cc: Jeykumar Sankaran
> Cc: Chandan Uddaraju
> Cc: Vara Reddy
> Cc: Tanmay Shah
> Cc: Rob Clark
> Fixes: 58fd7ae621e7 ("arm64: dts: qcom: sc7180: Update dts for DP phy inside
> QMP phy")
> Reported-by: Dmitry Baryshkov
> Signed-off-by: Douglas Anderson
> ---
Reviewed-by: Stephen Boyd
[PATCH] include: linux: Remove duplicate include of pgtable.h
linux/pgtable.h has been included at line 11 with annotation. So we remove the duplicate one at line 8. Signed-off-by: Wan Jiabing --- include/linux/crash_dump.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/linux/crash_dump.h b/include/linux/crash_dump.h index a5192b718dbe..be79a45d7aa3 100644 --- a/include/linux/crash_dump.h +++ b/include/linux/crash_dump.h @@ -5,7 +5,6 @@ #include #include #include -#include #include #include /* for pgprot_t */ -- 2.25.1
Re: [PATCH V3] exit: trigger panic when global init has exited
Hi,Oleg
> No, there is at least one alive init thread. If they all have exited, we have
> the thread which calls panic() above.
By current logic, setting PF_EXITING(exit_signals()) is before the
panic(),find_alive_thread() determines the PF_EXITING of all child
threads, the panic thread's PF_EXITING has been set before panic(),so
find_alive_thread() thinks this thread also dead, resulting in
find_alive_thread returning NULL.It is possible to trigger a
zap_pid_ns_processes()->BUG() in this case.
exit_signals(tsk); /* sets PF_EXITING */
...
group_dead = atomic_dec_and_test(>signal->live);
if (group_dead) {
if (unlikely(is_global_init(tsk)))
panic("Attempted to kill init!
exitcode=0x%08x\n",>//PF_EXITING has been set
tsk->signal->group_exit_code ?: (int)code);
===
> Why do you think so? It can affect _any_ code which runs under
> "if (group_dead)". Again, I don't see anything wrong, but I didn't even
> try to audit these code paths.
Yes,all places where checked the "signal->live" may be affected,but
even before my changes, each program that checks "signal->live" may
get different state(group_dead or not), depending on the timing of the
caller,this situation will not change after my change.
After my patch,"signal->live--" and other variable are set in a
different order(such as signal->live and PF_EXITING),this can cause
abnormalities in the logic associated with these two variables,that is
my thinking.
Of course, check all the "signal->live--" path is definitely
necessary,it's just the case above that we need more attention.
Thanks
Oleg Nesterov 于2021年3月23日周二 上午12:37写道：
>
> Hi,
>
> It seems that we don't understand each other.
>
> If we move atomic_dec_and_test(signal->live) and do
>
> if (group_dead && is_global_init)
> panic(...);
>
>
> before setting PF_EXITING like your patch does, then zap_pid_ns_processes()
> simply won't be called.
>
> Because:
>
> On 03/21, qianli zhao wrote:
> >
> > Hi,Oleg
> >
> > > How? Perhaps I missed something again, but I don't think this is possible.
> >
> > > zap_pid_ns_processes() simply won't be called, find_child_reaper() will
> > > see the !PF_EXITING thread which calls panic().
> >
> > > So I think this should be documented somehow, at least in the changelog.
> >
> > This problem occurs when both two init threads enter the do_exit,
> > One of the init thread is syscall sys_exit_group,and set SIGNAL_GROUP_EXIT
> > The other init thread perform ret_to_user()->get_signal() and found
> > SIGNAL_GROUP_EXIT is set,then do_group_exit()->do_exit(),since there
> > are no alive init threads it finally goes to
> > zap_pid_ns_processes()
>
> No, there is at least one alive init thread. If they all have exited, we have
> the thread which calls panic() above.
>
> > and BUG().
>
> so we don't need the SIGNAL_GROUP_EXIT check to avoid this BUG().
>
> What have I missed?
>
> Oleg.
>
Re: [PATCH 1/5] cifsd: add server handler and tranport layers
On Tue, Mar 23, 2021 at 12:01:22PM +0900, Namjae Jeon wrote: > > On Mon, Mar 22, 2021 at 02:13:40PM +0900, Namjae Jeon wrote: > > > +#define RESPONSE_BUF(w) ((void *)(w)->response_buf) > > > +#define REQUEST_BUF(w) ((void *)(w)->request_buf) > > > > Why do you do this obfuscation? > I don't remember exactly, but back then, It looked easier... > > > > > +#define RESPONSE_BUF_NEXT(w) \ > > > + ((void *)((w)->response_buf + (w)->next_smb2_rsp_hdr_off)) > > > +#define REQUEST_BUF_NEXT(w) \ > > > + ((void *)((w)->request_buf + (w)->next_smb2_rcv_hdr_off)) > > > > These obfuscations aren't even used; delete them > They are used in many place. Oh, argh. patch 2/5 was too big, so it didn't make it into the mailing list archive I was using to try to review this series. Please break it up into smaller pieces for next time!
[PATCH V2 6/6] PM / devfreq: imx8m-ddrc: remove imx8m_ddrc_get_dev_status
Current driver actually does not support simple ondemand governor
as it's unable to provide device load information. So removing
the unnecessary callback to avoid confusing.
Right now the driver is using userspace governor by default.
polling_ms was also dropped as it's not needed for non-ondemand
governor.
Signed-off-by: Dong Aisheng
---
drivers/devfreq/imx8m-ddrc.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/devfreq/imx8m-ddrc.c b/drivers/devfreq/imx8m-ddrc.c
index bc82d3653bff..ecb9375aa877 100644
--- a/drivers/devfreq/imx8m-ddrc.c
+++ b/drivers/devfreq/imx8m-ddrc.c
@@ -280,18 +280,6 @@ static int imx8m_ddrc_get_cur_freq(struct device *dev,
unsigned long *freq)
return 0;
}
-static int imx8m_ddrc_get_dev_status(struct device *dev,
-struct devfreq_dev_status *stat)
-{
- struct imx8m_ddrc *priv = dev_get_drvdata(dev);
-
- stat->busy_time = 0;
- stat->total_time = 0;
- stat->current_frequency = clk_get_rate(priv->dram_core);
-
- return 0;
-}
-
static int imx8m_ddrc_init_freq_info(struct device *dev)
{
struct imx8m_ddrc *priv = dev_get_drvdata(dev);
@@ -429,9 +417,7 @@ static int imx8m_ddrc_probe(struct platform_device *pdev)
if (ret < 0)
goto err;
- priv->profile.polling_ms = 1000;
priv->profile.target = imx8m_ddrc_target;
- priv->profile.get_dev_status = imx8m_ddrc_get_dev_status;
priv->profile.exit = imx8m_ddrc_exit;
priv->profile.get_cur_freq = imx8m_ddrc_get_cur_freq;
priv->profile.initial_freq = clk_get_rate(priv->dram_core);
--
2.25.1
[PATCH V2 5/6] PM / devfreq: governor: optimize simpleondemand get_target_freq
The device profile up_threshold/down_differential only needs to be initialized once when calling devm_devfreq_add_device. It's unnecessary to put the data check logic in the hot path (.get_target_freq()) where it will be called all the time during polling. Instead, we only check and initialize it one time during DEVFREQ_GOV_START. This also helps check data validability in advance during DEVFREQ_GOV_START rather than checking it later when running .get_target_freq(). Signed-off-by: Dong Aisheng --- Change Log: v1->v2: * rebase to devfreq-testing --- drivers/devfreq/devfreq.c | 24 +- drivers/devfreq/governor_simpleondemand.c | 31 +++ 2 files changed, 26 insertions(+), 29 deletions(-) diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c index cacda7d1f858..270e51f5318f 100644 --- a/drivers/devfreq/devfreq.c +++ b/drivers/devfreq/devfreq.c @@ -1908,9 +1908,7 @@ static ssize_t up_threshold_show(struct device *dev, if (!df->profile) return -EINVAL; - return sprintf(buf, "%d\n", df->profile->up_threshold - ? df->profile->up_threshold - : DEVFREQ_UP_THRESHOLD); + return sprintf(buf, "%d\n", df->profile->up_threshold); } static ssize_t up_threshold_store(struct device *dev, @@ -1934,9 +1932,7 @@ static ssize_t up_threshold_store(struct device *dev, if (value > 100) value = 100; - down_differential = df->profile->down_differential - ? df->profile->down_differential - : DEVFREQ_DOWN_DIFFERENCTIAL; + down_differential = df->profile->down_differential; if (value < down_differential) value = down_differential; @@ -1961,9 +1957,7 @@ static ssize_t down_differential_show(struct device *dev, if (!df->profile) return -EINVAL; - return sprintf(buf, "%d\n", df->profile->down_differential - ? df->profile->down_differential - : DEVFREQ_DOWN_DIFFERENCTIAL); + return sprintf(buf, "%d\n", df->profile->down_differential); } static ssize_t down_differential_store(struct device *dev, @@ -1984,9 +1978,7 @@ static ssize_t down_differential_store(struct device *dev, if (ret != 1) return -EINVAL; - up_threshold = df->profile->up_threshold - ? df->profile->up_threshold - : DEVFREQ_UP_THRESHOLD; + up_threshold = df->profile->up_threshold; if (value > up_threshold) value = up_threshold; @@ -2113,16 +2105,12 @@ static int devfreq_summary_show(struct seq_file *s, void *data) polling_ms = 0; if (IS_SUPPORTED_ATTR(devfreq->governor->attrs, UP_THRESHOLD)) - up_threshold = devfreq->profile->up_threshold - ? devfreq->profile->up_threshold - : DEVFREQ_UP_THRESHOLD; + up_threshold = devfreq->profile->up_threshold; else up_threshold = 0; if (IS_SUPPORTED_ATTR(devfreq->governor->attrs, DOWN_DIFF)) - down_differential = devfreq->profile->down_differential - ? devfreq->profile->down_differential - : DEVFREQ_DOWN_DIFFERENCTIAL; + down_differential = devfreq->profile->down_differential; else down_differential = 0; mutex_unlock(>lock); diff --git a/drivers/devfreq/governor_simpleondemand.c b/drivers/devfreq/governor_simpleondemand.c index 93f6061667d9..3e195b46554a 100644 --- a/drivers/devfreq/governor_simpleondemand.c +++ b/drivers/devfreq/governor_simpleondemand.c @@ -18,8 +18,8 @@ static int devfreq_simple_ondemand_func(struct devfreq *df, int err; struct devfreq_dev_status *stat; unsigned long long a, b; - unsigned int dfso_upthreshold = DEVFREQ_UP_THRESHOLD; - unsigned int dfso_downdifferential = DEVFREQ_DOWN_DIFFERENCTIAL; + unsigned int dfso_upthreshold = df->profile->up_threshold; + unsigned int dfso_downdifferential = df->profile->down_differential; err = devfreq_update_stats(df); if (err) @@ -27,15 +27,6 @@ static int devfreq_simple_ondemand_func(struct devfreq *df, stat = >last_status; - if (df->profile->up_threshold) - dfso_upthreshold = df->profile->up_threshold; - if (df->profile->down_differential) - dfso_downdifferential = df->profile->down_differential; - - if (dfso_upthreshold > 100 || - dfso_upthreshold < dfso_downdifferential) - return -EINVAL; -
[PATCH V2 1/6] PM / devfreq: fix build error when DEVFREQ_GOV_PASSIVE enabled
drivers/devfreq/devfreq.c: In function ‘devfreq_transitions_show’:
drivers/devfreq/devfreq.c:2188:25: error: ‘struct devfreq’ has no member named
‘governor_name’; did you mean ‘governor’?
2188 | if (!strncmp(devfreq->governor_name,
| ^
| governor
Fixes: 5cc75e9252e9 ("PM / devfreq: Add devfreq_transitions debugfs file")
Signed-off-by: Dong Aisheng
---
drivers/devfreq/devfreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index d625b268adf2..107badfc6b2b 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -2185,7 +2185,7 @@ static int devfreq_transitions_show(struct seq_file *s,
void *data)
continue;
#if IS_ENABLED(CONFIG_DEVFREQ_GOV_PASSIVE)
- if (!strncmp(devfreq->governor_name,
+ if (!strncmp(devfreq->governor->name,
DEVFREQ_GOV_PASSIVE, DEVFREQ_NAME_LEN)) {
struct devfreq_passive_data *data = devfreq->data;
--
2.25.1
[PATCH V2 3/6] PM / devfreq: Remove the invalid description for get_target_freq
First of all, no_central_polling was removed since
commit 7e6fdd4bad03 ("PM / devfreq: Core updates to support devices
which can idle")
Secondly, get_target_freq() is not only called only with update_devfreq()
notified by OPP now, but also min/max freq qos notifier.
So remove this invalid description now to avoid confusing.
Signed-off-by: Dong Aisheng
---
Documentation/ABI/testing/sysfs-class-devfreq | 5 +
drivers/devfreq/governor.h| 2 --
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-class-devfreq
b/Documentation/ABI/testing/sysfs-class-devfreq
index 22408cfa7ed2..e71595c84f22 100644
--- a/Documentation/ABI/testing/sysfs-class-devfreq
+++ b/Documentation/ABI/testing/sysfs-class-devfreq
@@ -97,10 +97,7 @@ Description:
object. The values are represented in ms. If the value is
less than 1 jiffy, it is considered to be 0, which means
no polling. This value is meaningless if the governor is
- not polling; thus. If the governor is not using
- devfreq-provided central polling
- (/sys/class/devfreq/.../central_polling is 0), this value
- may be useless.
+ not polling.
A list of governors that support the node:
- simple_ondmenad
diff --git a/drivers/devfreq/governor.h b/drivers/devfreq/governor.h
index 48736a2ae970..9d72f5b66bfa 100644
--- a/drivers/devfreq/governor.h
+++ b/drivers/devfreq/governor.h
@@ -67,8 +67,6 @@
* Basically, get_target_freq will run
* devfreq_dev_profile.get_dev_status() to get the
* status of the device (load = busy_time / total_time).
- * If no_central_polling is set, this callback is called
- * only with update_devfreq() notified by OPP.
* @event_handler: Callback for devfreq core framework to notify events
* to governors. Events include per device governor
* init and exit, opp changes out of devfreq, suspend
--
2.25.1
[PATCH V2 0/6] PM / devfreq: a few small fixes and improvements
A few small fixes and improvements ChangeLog: v1->v2: * squash a few patches * rebase to devfreq-testing * drop two patches which are already in devfreq-next Dong Aisheng (6): PM / devfreq: fix build error when DEVFREQ_GOV_PASSIVE enabled PM / devfreq: Use more accurate returned new_freq as resume_freq PM / devfreq: Remove the invalid description for get_target_freq PM / devfreq: bail out early if no freq changes in devfreq_set_target PM / devfreq: governor: optimize simpleondemand get_target_freq PM / devfreq: imx8m-ddrc: remove imx8m_ddrc_get_dev_status Documentation/ABI/testing/sysfs-class-devfreq | 5 +-- drivers/devfreq/devfreq.c | 37 +++ drivers/devfreq/governor.h| 2 - drivers/devfreq/governor_simpleondemand.c | 31 ++-- drivers/devfreq/imx8m-ddrc.c | 14 --- 5 files changed, 35 insertions(+), 54 deletions(-) -- 2.25.1
[PATCH V2 2/6] PM / devfreq: Use more accurate returned new_freq as resume_freq
Use the more accurate returned new_freq as resume_freq.
It's the same as how devfreq->previous_freq was updated.
Fixes: 83f8ca45afbf0 ("PM / devfreq: add support for suspend/resume of a
devfreq device")
Signed-off-by: Dong Aisheng
---
drivers/devfreq/devfreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 107badfc6b2b..b537fd9602cd 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -443,7 +443,7 @@ static int devfreq_set_target(struct devfreq *devfreq,
unsigned long new_freq,
devfreq->previous_freq = new_freq;
if (devfreq->suspend_freq)
- devfreq->resume_freq = cur_freq;
+ devfreq->resume_freq = new_freq;
return err;
}
--
2.25.1
[PATCH V2 4/6] PM / devfreq: bail out early if no freq changes in devfreq_set_target
It's unnecessary to set the same freq again and run notifier calls.
Signed-off-by: Dong Aisheng
---
drivers/devfreq/devfreq.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index b537fd9602cd..cacda7d1f858 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -403,13 +403,16 @@ static int devfreq_set_target(struct devfreq *devfreq,
unsigned long new_freq,
{
struct devfreq_freqs freqs;
unsigned long cur_freq;
- int err = 0;
+ int err;
if (devfreq->profile->get_cur_freq)
devfreq->profile->get_cur_freq(devfreq->dev.parent, _freq);
else
cur_freq = devfreq->previous_freq;
+ if (new_freq == cur_freq)
+ return 0;
+
freqs.old = cur_freq;
freqs.new = new_freq;
devfreq_notify_transition(devfreq, , DEVFREQ_PRECHANGE);
@@ -426,7 +429,7 @@ static int devfreq_set_target(struct devfreq *devfreq,
unsigned long new_freq,
* and DEVFREQ_POSTCHANGE because for showing the correct frequency
* change order of between devfreq device and passive devfreq device.
*/
- if (trace_devfreq_frequency_enabled() && new_freq != cur_freq)
+ if (trace_devfreq_frequency_enabled())
trace_devfreq_frequency(devfreq, new_freq, cur_freq);
devfreq_update_transitions(devfreq, cur_freq, new_freq,
@@ -445,7 +448,7 @@ static int devfreq_set_target(struct devfreq *devfreq,
unsigned long new_freq,
if (devfreq->suspend_freq)
devfreq->resume_freq = new_freq;
- return err;
+ return 0;
}
/**
--
2.25.1
[PATCH] clk: imx: reference preceded by free
From: Jian Dong
when register failed, clk will be freed, it will generate dangling pointer
problem in later reference. it should return directly.
Signed-off-by: Jian Dong
---
drivers/clk/imx/clk-lpcg-scu.c | 1 +
drivers/clk/imx/clk-scu.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/clk/imx/clk-lpcg-scu.c b/drivers/clk/imx/clk-lpcg-scu.c
index 77be763..dd5abd0 100644
--- a/drivers/clk/imx/clk-lpcg-scu.c
+++ b/drivers/clk/imx/clk-lpcg-scu.c
@@ -114,6 +114,7 @@ struct clk_hw *__imx_clk_lpcg_scu(struct device *dev, const
char *name,
if (ret) {
kfree(clk);
hw = ERR_PTR(ret);
+ return hw;
}
if (dev)
diff --git a/drivers/clk/imx/clk-scu.c b/drivers/clk/imx/clk-scu.c
index 1f5518b7..f89b4da 100644
--- a/drivers/clk/imx/clk-scu.c
+++ b/drivers/clk/imx/clk-scu.c
@@ -426,6 +426,7 @@ struct clk_hw *__imx_clk_scu(struct device *dev, const char
*name,
if (ret) {
kfree(clk);
hw = ERR_PTR(ret);
+ return hw;
}
if (dev)
--
1.9.1
Re: [PATCH RFC v2 8/8] selftests/perf: Add kselftest for remove_on_exec
On Mon, Mar 22, 2021 at 6:24 AM Marco Elver wrote: > > On Wed, Mar 10, 2021 at 11:41AM +0100, Marco Elver wrote: > > Add kselftest to test that remove_on_exec removes inherited events from > > child tasks. > > > > Signed-off-by: Marco Elver > > To make compatible with more recent libc, we'll need to fixup the tests > with the below. > > Also, I've seen that tools/perf/tests exists, however it seems to be > primarily about perf-tool related tests. Is this correct? > > I'd propose to keep these purely kernel ABI related tests separate, and > that way we can also make use of the kselftests framework which will > also integrate into various CI systems such as kernelci.org. Perhaps there is a way to have both? Having the perf tool spot an errant kernel feels like a feature. There are also tools/lib/perf/tests and Vince Weaver's tests [1]. It is possible to run standalone tests from within perf test by having them be executed by a shell test. Thanks, Ian [1] https://github.com/deater/perf_event_tests > Thanks, > -- Marco > > -- >8 -- > > diff --git a/tools/testing/selftests/perf_events/remove_on_exec.c > b/tools/testing/selftests/perf_events/remove_on_exec.c > index e176b3a74d55..f89d0cfdb81e 100644 > --- a/tools/testing/selftests/perf_events/remove_on_exec.c > +++ b/tools/testing/selftests/perf_events/remove_on_exec.c > @@ -13,6 +13,11 @@ > #define __have_siginfo_t 1 > #define __have_sigval_t 1 > #define __have_sigevent_t 1 > +#define __siginfo_t_defined > +#define __sigval_t_defined > +#define __sigevent_t_defined > +#define _BITS_SIGINFO_CONSTS_H 1 > +#define _BITS_SIGEVENT_CONSTS_H 1 > > #include > #include > diff --git a/tools/testing/selftests/perf_events/sigtrap_threads.c > b/tools/testing/selftests/perf_events/sigtrap_threads.c > index 7ebb9bb34c2e..b9a7d4b64b3c 100644 > --- a/tools/testing/selftests/perf_events/sigtrap_threads.c > +++ b/tools/testing/selftests/perf_events/sigtrap_threads.c > @@ -13,6 +13,11 @@ > #define __have_siginfo_t 1 > #define __have_sigval_t 1 > #define __have_sigevent_t 1 > +#define __siginfo_t_defined > +#define __sigval_t_defined > +#define __sigevent_t_defined > +#define _BITS_SIGINFO_CONSTS_H 1 > +#define _BITS_SIGEVENT_CONSTS_H 1 > > #include > #include
Re: [PATCH v6] selftests/x86: Use getauxval() to simplify the code in sgx
Hi, On 3/15/21 9:02 PM, Jarkko Sakkinen wrote: On Sun, Mar 14, 2021 at 07:16:21PM +0800, Tianjia Zhang wrote: Simplify the sgx code implemntation by using library function getauxval() instead of a custom function to get the base address of vDSO. Signed-off-by: Tianjia Zhang Reviewed-by: Jarkko Sakkinen Acked-by: Shuah Khan Shuah, Boris, which tree this should be picked? /Jarkko Take time to look at this. Best regards, Tianjia
[PATCH] mm/page_alloc: Duplicate include linux/vmalloc.h
linux/vmalloc.h is repeatedly in the file page_alloc.c Signed-off-by: zhouchuangao --- mm/page_alloc.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index c53fe4f..5adf9c1 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -72,8 +72,6 @@ #include #include #include -#include - #include #include #include -- 2.7.4
[PATCH] arch: powerpc: Remove duplicate include of clock.h
linux/sched/clock.h has been included at line 33. So we remove the duplicate one at line 56. For better understanding, we also move sched/cputime.h under the sched including segment. Signed-off-by: Wan Jiabing --- arch/powerpc/kernel/time.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c index b67d93a609a2..e2766e0e2a3a 100644 --- a/arch/powerpc/kernel/time.c +++ b/arch/powerpc/kernel/time.c @@ -31,6 +31,7 @@ #include #include #include +#include #include #include #include @@ -52,8 +53,6 @@ #include #include #include -#include -#include #include #include -- 2.25.1
