ipmi: Add Phytium KCS IPMI BMC driver support #134

lyt31 · 2024-05-13T07:57:50Z

This driver exposes the KCS interface on Phytium SOCs as a character device. Such SOCs are commonly used as BMCs and this driver implements the BMC side of the KCS interface.

deepin-ci-robot · 2024-05-13T07:58:06Z

Hi @lyt31. Thanks for your PR.

I'm waiting for a deepin-community member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Avenger-285714 · 2024-05-13T08:12:35Z

/ok-to-test

Avenger-285714 · 2024-05-13T08:58:14Z

drivers/char/ipmi/Kconfig

+	depends on ARCH_PHYTIUM
+	select IPMI_KCS_BMC
+	select REGMAP_MMIO
+	tristate "PHYTIUM KCS IPMI BMC driver"


麻烦在Kconfig中统一写法，建议在Prompt这种解释性文字中使用"Phytium"代替“PHYTIUM”，这样可识度更高

Avenger-285714 · 2024-05-13T09:17:09Z

drivers/char/ipmi/kcs_bmc_phytium.c

+		}
+	}
+}
+


多了个空行嘛

Avenger-285714 · 2024-05-13T09:17:33Z

drivers/char/ipmi/kcs_bmc_phytium.c

+
+	rc = regmap_update_bits(priv->map, reg, mask, val);
+	WARN(rc != 0, "regmap_update_bits() failed: %d\n", rc);
+}


少了个空行嘛

This driver exposes the KCS interface on Phytium SOCs as a character device. Such SOCs are commonly used as BMCs and this driver implements the BMC side of the KCS interface. Signed-off-by: Li Yuting <[email protected]> Signed-off-by: Cheng Quan <[email protected]> Signed-off-by: Chen Zhenhua <[email protected]> Signed-off-by: Chen Baozi <[email protected]> Signed-off-by: Wang Yinfeng <[email protected]>

Avenger-285714 · 2024-05-13T09:32:54Z

Great! Love from deepin kernel SIG.

Avenger-285714 · 2024-05-13T09:32:59Z

/approve

deepin-ci-robot · 2024-05-13T09:33:09Z

deepin pr auto review

This patch adds a new driver for the KCS BMC device. The driver is
specific to the Phytium server board and is used to communicate with
the onboard KCS BMC device. The driver provides methods for reading
and writing data to the KCS BMC device, and manages its lifecycle
including initialization, configuration, and removal.

deepin-ci-robot · 2024-05-13T10:18:21Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Avenger-285714
Once this PR has been reviewed and has the lgtm label, please assign yukarichiba for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

https:/raw.githubusercontent.com/deepin-community/template-repository/master/debian/deepin/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ Upstream commit 6ede14a2c6365e7e5d855643c7c8390b5268c467 ] The fbnic driver was presenting with the following locking assert coming out of a PM resume: [ 42.208116][ T164] RTNL: assertion failed at drivers/net/phy/phylink.c (2611) [ 42.208492][ T164] WARNING: CPU: 1 PID: 164 at drivers/net/phy/phylink.c:2611 phylink_resume+0x190/0x1e0 [ 42.208872][ T164] Modules linked in: [ 42.209140][ T164] CPU: 1 UID: 0 PID: 164 Comm: bash Not tainted 6.17.0-rc2-virtme deepin-community#134 PREEMPT(full) [ 42.209496][ T164] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014 [ 42.209861][ T164] RIP: 0010:phylink_resume+0x190/0x1e0 [ 42.210057][ T164] Code: 83 e5 01 0f 85 b0 fe ff ff c6 05 1c cd 3e 02 01 90 ba 33 0a 00 00 48 c7 c6 20 3a 1d a5 48 c7 c7 e0 3e 1d a5 e8 21 b8 90 fe 90 <0f> 0b 90 90 e9 86 fe ff ff e8 42 ea 1f ff e9 e2 fe ff ff 48 89 ef [ 42.210708][ T164] RSP: 0018:ffffc90000affbd8 EFLAGS: 00010296 [ 42.210983][ T164] RAX: 0000000000000000 RBX: ffff8880078d8400 RCX: 0000000000000000 [ 42.211235][ T164] RDX: 0000000000000000 RSI: 1ffffffff4f10938 RDI: 0000000000000001 [ 42.211466][ T164] RBP: 0000000000000000 R08: ffffffffa2ae79ea R09: fffffbfff4b3eb84 [ 42.211707][ T164] R10: 0000000000000003 R11: 0000000000000000 R12: ffff888007ad8000 [ 42.211997][ T164] R13: 0000000000000002 R14: ffff888006a18800 R15: ffffffffa34c59e0 [ 42.212234][ T164] FS: 00007f0dc8e39740(0000) GS:ffff88808f51f000(0000) knlGS:0000000000000000 [ 42.212505][ T164] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 42.212704][ T164] CR2: 00007f0dc8e9fe10 CR3: 000000000b56d003 CR4: 0000000000772ef0 [ 42.213227][ T164] PKRU: 55555554 [ 42.213366][ T164] Call Trace: [ 42.213483][ T164] <TASK> [ 42.213565][ T164] __fbnic_pm_attach.isra.0+0x8e/0xa0 [ 42.213725][ T164] pci_reset_function+0x116/0x1d0 [ 42.213895][ T164] reset_store+0xa0/0x100 [ 42.214025][ T164] ? pci_dev_reset_attr_is_visible+0x50/0x50 [ 42.214221][ T164] ? sysfs_file_kobj+0xc1/0x1e0 [ 42.214374][ T164] ? sysfs_kf_write+0x65/0x160 [ 42.214526][ T164] kernfs_fop_write_iter+0x2f8/0x4c0 [ 42.214677][ T164] ? kernfs_vma_page_mkwrite+0x1f0/0x1f0 [ 42.214836][ T164] new_sync_write+0x308/0x6f0 [ 42.214987][ T164] ? __lock_acquire+0x34c/0x740 [ 42.215135][ T164] ? new_sync_read+0x6f0/0x6f0 [ 42.215288][ T164] ? lock_acquire.part.0+0xbc/0x260 [ 42.215440][ T164] ? ksys_write+0xff/0x200 [ 42.215590][ T164] ? perf_trace_sched_switch+0x6d0/0x6d0 [ 42.215742][ T164] vfs_write+0x65e/0xbb0 [ 42.215876][ T164] ksys_write+0xff/0x200 [ 42.215994][ T164] ? __ia32_sys_read+0xc0/0xc0 [ 42.216141][ T164] ? do_user_addr_fault+0x269/0x9f0 [ 42.216292][ T164] ? rcu_is_watching+0x15/0xd0 [ 42.216442][ T164] do_syscall_64+0xbb/0x360 [ 42.216591][ T164] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 42.216784][ T164] RIP: 0033:0x7f0dc8ea9986 A bit of digging showed that we were invoking the phylink_resume as a part of the fbnic_up path when we were enabling the service task while not holding the RTNL lock. We should be enabling this sooner as a part of the ndo_open path and then just letting the service task come online later. This will help to enforce the correct locking and brings the phylink interface online at the same time as the network interface, instead of at a later time. I tested this on QEMU to verify this was working by putting the system to sleep using "echo mem > /sys/power/state" to put the system to sleep in the guest and then using the command "system_wakeup" in the QEMU monitor. Fixes: 6968437 ("eth: fbnic: Add link detection") Signed-off-by: Alexander Duyck <[email protected]> Reviewed-by: Przemek Kitszel <[email protected]> Link: https://patch.msgid.link/175616257316.1963577.12238158800417771119.stgit@ahduyck-xeon-server.home.arpa Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 7aab65c62a8a8b48c02e600fe9367b2af662fcb6)

[ Upstream commit 6ede14a2c6365e7e5d855643c7c8390b5268c467 ] The fbnic driver was presenting with the following locking assert coming out of a PM resume: [ 42.208116][ T164] RTNL: assertion failed at drivers/net/phy/phylink.c (2611) [ 42.208492][ T164] WARNING: CPU: 1 PID: 164 at drivers/net/phy/phylink.c:2611 phylink_resume+0x190/0x1e0 [ 42.208872][ T164] Modules linked in: [ 42.209140][ T164] CPU: 1 UID: 0 PID: 164 Comm: bash Not tainted 6.17.0-rc2-virtme #134 PREEMPT(full) [ 42.209496][ T164] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014 [ 42.209861][ T164] RIP: 0010:phylink_resume+0x190/0x1e0 [ 42.210057][ T164] Code: 83 e5 01 0f 85 b0 fe ff ff c6 05 1c cd 3e 02 01 90 ba 33 0a 00 00 48 c7 c6 20 3a 1d a5 48 c7 c7 e0 3e 1d a5 e8 21 b8 90 fe 90 <0f> 0b 90 90 e9 86 fe ff ff e8 42 ea 1f ff e9 e2 fe ff ff 48 89 ef [ 42.210708][ T164] RSP: 0018:ffffc90000affbd8 EFLAGS: 00010296 [ 42.210983][ T164] RAX: 0000000000000000 RBX: ffff8880078d8400 RCX: 0000000000000000 [ 42.211235][ T164] RDX: 0000000000000000 RSI: 1ffffffff4f10938 RDI: 0000000000000001 [ 42.211466][ T164] RBP: 0000000000000000 R08: ffffffffa2ae79ea R09: fffffbfff4b3eb84 [ 42.211707][ T164] R10: 0000000000000003 R11: 0000000000000000 R12: ffff888007ad8000 [ 42.211997][ T164] R13: 0000000000000002 R14: ffff888006a18800 R15: ffffffffa34c59e0 [ 42.212234][ T164] FS: 00007f0dc8e39740(0000) GS:ffff88808f51f000(0000) knlGS:0000000000000000 [ 42.212505][ T164] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 42.212704][ T164] CR2: 00007f0dc8e9fe10 CR3: 000000000b56d003 CR4: 0000000000772ef0 [ 42.213227][ T164] PKRU: 55555554 [ 42.213366][ T164] Call Trace: [ 42.213483][ T164] <TASK> [ 42.213565][ T164] __fbnic_pm_attach.isra.0+0x8e/0xa0 [ 42.213725][ T164] pci_reset_function+0x116/0x1d0 [ 42.213895][ T164] reset_store+0xa0/0x100 [ 42.214025][ T164] ? pci_dev_reset_attr_is_visible+0x50/0x50 [ 42.214221][ T164] ? sysfs_file_kobj+0xc1/0x1e0 [ 42.214374][ T164] ? sysfs_kf_write+0x65/0x160 [ 42.214526][ T164] kernfs_fop_write_iter+0x2f8/0x4c0 [ 42.214677][ T164] ? kernfs_vma_page_mkwrite+0x1f0/0x1f0 [ 42.214836][ T164] new_sync_write+0x308/0x6f0 [ 42.214987][ T164] ? __lock_acquire+0x34c/0x740 [ 42.215135][ T164] ? new_sync_read+0x6f0/0x6f0 [ 42.215288][ T164] ? lock_acquire.part.0+0xbc/0x260 [ 42.215440][ T164] ? ksys_write+0xff/0x200 [ 42.215590][ T164] ? perf_trace_sched_switch+0x6d0/0x6d0 [ 42.215742][ T164] vfs_write+0x65e/0xbb0 [ 42.215876][ T164] ksys_write+0xff/0x200 [ 42.215994][ T164] ? __ia32_sys_read+0xc0/0xc0 [ 42.216141][ T164] ? do_user_addr_fault+0x269/0x9f0 [ 42.216292][ T164] ? rcu_is_watching+0x15/0xd0 [ 42.216442][ T164] do_syscall_64+0xbb/0x360 [ 42.216591][ T164] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 42.216784][ T164] RIP: 0033:0x7f0dc8ea9986 A bit of digging showed that we were invoking the phylink_resume as a part of the fbnic_up path when we were enabling the service task while not holding the RTNL lock. We should be enabling this sooner as a part of the ndo_open path and then just letting the service task come online later. This will help to enforce the correct locking and brings the phylink interface online at the same time as the network interface, instead of at a later time. I tested this on QEMU to verify this was working by putting the system to sleep using "echo mem > /sys/power/state" to put the system to sleep in the guest and then using the command "system_wakeup" in the QEMU monitor. Fixes: 6968437 ("eth: fbnic: Add link detection") Signed-off-by: Alexander Duyck <[email protected]> Reviewed-by: Przemek Kitszel <[email protected]> Link: https://patch.msgid.link/175616257316.1963577.12238158800417771119.stgit@ahduyck-xeon-server.home.arpa Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 7aab65c62a8a8b48c02e600fe9367b2af662fcb6)

deepin-ci-robot requested a review from justforlxz May 13, 2024 07:57

deepin-ci-robot added the needs-ok-to-test label May 13, 2024

deepin-ci-robot added ok-to-test and removed needs-ok-to-test labels May 13, 2024

Avenger-285714 reviewed May 13, 2024

View reviewed changes

Avenger-285714 merged commit 1472a37 into deepin-community:linux-6.6.y May 13, 2024

MingcongBai mentioned this pull request May 22, 2024

(kernel-rolling) ipmi: Add Phytium KCS IPMI BMC driver support #180

Closed

3 tasks

MingcongBai mentioned this pull request Jun 26, 2024

【跟踪】 6.9 系列合并 6.6 补丁情况一览 deepin-community/kernel-rolling#1

Closed

MingcongBai mentioned this pull request Aug 20, 2024

【跟踪】 6.10 系列合并 6.6 补丁情况一览 deepin-community/kernel-rolling#10

Closed

MingcongBai mentioned this pull request Nov 12, 2024

【跟踪】6.12 系列合并 6.6 补丁情况一览 deepin-community/kernel-rolling#11

Open

ipmi: Add Phytium KCS IPMI BMC driver support #134

ipmi: Add Phytium KCS IPMI BMC driver support #134

Uh oh!

Conversation

lyt31 commented May 13, 2024

Uh oh!

deepin-ci-robot commented May 13, 2024

Uh oh!

Avenger-285714 commented May 13, 2024

Uh oh!

Avenger-285714 May 13, 2024

Choose a reason for hiding this comment

Uh oh!

lyt31 May 13, 2024

Choose a reason for hiding this comment

Uh oh!

Avenger-285714 May 13, 2024

Choose a reason for hiding this comment

Uh oh!

lyt31 May 13, 2024

Choose a reason for hiding this comment

Uh oh!

Avenger-285714 May 13, 2024

Choose a reason for hiding this comment

Uh oh!

lyt31 May 13, 2024

Choose a reason for hiding this comment

Uh oh!

Avenger-285714 commented May 13, 2024

Uh oh!

Avenger-285714 commented May 13, 2024

Uh oh!

deepin-ci-robot commented May 13, 2024

deepin pr auto review

Uh oh!

deepin-ci-robot commented May 13, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants