blaster4385/linux-IllusionX/drivers/firmware/arm_scmi, branch v6.12.1

Merge tag 'pmdomain-v6.12-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm

2024-11-15T18:20:17Z

Pull pmdomain fixes from Ulf Hansson: "pmdomain core: - Add GENPD_FLAG_DEV_NAME_FW flag to generate unique names pmdomain providers: - arm: Use FLAG_DEV_NAME_FW to ensure unique names - imx93-blk-ctrl: Fix the remove path arm_scmi/qcom-cpucp: - Report duplicate OPPs as firmware bugs for arm_scmi - Skip OPP duplicates for arm_scmi - Mark the qcom-cpucp mailbox irq with IRQF_NO_SUSPEND flag" * tag 'pmdomain-v6.12-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm: mailbox: qcom-cpucp: Mark the irq with IRQF_NO_SUSPEND flag firmware: arm_scmi: Report duplicate opps as firmware bugs firmware: arm_scmi: Skip opp duplicates pmdomain: imx93-blk-ctrl: correct remove path pmdomain: arm: Use FLAG_DEV_NAME_FW to ensure unique names pmdomain: core: Add GENPD_FLAG_DEV_NAME_FW flag

firmware: arm_scmi: Report duplicate opps as firmware bugs

2024-11-12T18:45:25Z

Duplicate opps reported by buggy SCP firmware currently show up as warnings even though the only functional impact is that the level/index remain inaccessible. Make it less scary for the end user by using dev_info instead, along with FW_BUG tag. Suggested-by: Johan Hovold Signed-off-by: Sibi Sankar Reviewed-by: Cristian Marussi Reviewed-by: Florian Fainelli Reviewed-by: Sudeep Holla Cc: stable@vger.kernel.org Message-ID: <20241030125512.2884761-4-quic_sibis@quicinc.com> Signed-off-by: Ulf Hansson

firmware: arm_scmi: Skip opp duplicates

2024-11-12T18:45:25Z

Buggy firmware can reply with duplicated PERF opps descriptors. Ensure that the bad duplicates reported by the platform firmware doesn't get added to the opp-tables. Reported-by: Johan Hovold Closes: https://lore.kernel.org/lkml/ZoQjAWse2YxwyRJv@hovoldconsulting.com/ Signed-off-by: Cristian Marussi Tested-by: Johan Hovold Reviewed-by: Sudeep Holla Cc: stable@vger.kernel.org Message-ID: <20241030125512.2884761-3-quic_sibis@quicinc.com> Signed-off-by: Ulf Hansson

Merge tag 'scmi-fixes-6.12-2' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into HEAD

2024-11-01T14:48:07Z

Arm SCMI fixes for v6.12(part 2) Couple of fixes to address slab-use-after-free in scmi_bus_notifier() via scmi_dev->name and possible incorrect clear channel transport operation on A2P channel if some sort of P2A only messages are initiated on A2P channel(occurs when stress tested passing /dev/random to the channel). Apart from this, there are fixes to address missing "arm" prefix in the recently added property max-rx-timeout-ms which was missed in the review but was identified when further additions to the same binding were getting reviewed. * tag 'scmi-fixes-6.12-2' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_scmi: Use vendor string in max-rx-timeout-ms dt-bindings: firmware: arm,scmi: Add missing vendor string firmware: arm_scmi: Reject clear channel request on A2P firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier() Link: https://lore.kernel.org/r/20241031172734.3109140-1-sudeep.holla@arm.com Signed-off-by: Arnd Bergmann

firmware: arm_scmi: Use vendor string in max-rx-timeout-ms

2024-10-28T14:49:27Z

The original optional property was missing a vendor string prefix; this has been rectified. Fix the naming of such optional property in code too. Cc: Peng Fan Fixes: 1780e411ef94 ("firmware: arm_scmi: Use max-rx-timeout-ms from devicetree") Signed-off-by: Cristian Marussi Message-Id: <20241028120151.1301177-8-cristian.marussi@arm.com> Signed-off-by: Sudeep Holla

firmware: arm_scmi: Reject clear channel request on A2P

2024-10-22T08:55:28Z

The clear channel transport operation is supposed to be called exclusively on the P2A channel from the agent, since it relinquishes the ownership of the channel to the platform, after this latter has initiated some sort of P2A communication. Make sure that, if it is ever called on a A2P, is logged and ignored. Signed-off-by: Cristian Marussi Reviewed-by: Florian Fainelli Message-Id: <20241021171544.2579551-1-cristian.marussi@arm.com> Signed-off-by: Sudeep Holla

firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier()

2024-10-22T08:53:51Z

Merge tag 'scmi-fixes-6.12' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes

2024-10-15T20:39:43Z

Arm SCMI fixes for v6.12 Couple of fixes to address the issues found and reported on Broadcom STB platforms following the recent refactor of all the SCMI transports as standalone drivers. One of the issue is that the effective timeout value is much less than the intended value due to the way mailbox messages are queues in the mailbox framework. Since we block or serialise the shmem access anyway, there is no point in utilizing mailbox queues. The issue is fixed with exclusive lock on the channel when sending the message. The other issues is actually non-issue for upstream, but the workaround is just changing the link order of the transport drivers which enables Broadcom STB platforms to run both upstream and custom downstream kernel without any device tree changes. So pushing this to help them test upstream seamlessly as it has no practical or theoretical impact for others. There is also a fix to address possible double freeing of the name string in scmi_debugfs_common_cleanup() when devm_add_action_or_reset() fails. * tag 'scmi-fixes-6.12' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_scmi: Queue in scmi layer for mailbox implementation firmware: arm_scmi: Give SMC transport precedence over mailbox firmware: arm_scmi: Fix the double free in scmi_debugfs_common_setup() Link: https://lore.kernel.org/r/20241015185128.1000604-1-sudeep.holla@arm.com Signed-off-by: Arnd Bergmann

firmware: arm_scmi: Queue in scmi layer for mailbox implementation

2024-10-14T20:36:46Z

send_message() does not block in the MBOX implementation. This is because the mailbox layer has its own queue. However, this confuses the per xfer timeouts as they all start their timeout ticks in parallel. Consider a case where the xfer timeout is 30ms and a SCMI transaction takes 25ms: | 0ms: Message #0 is queued in mailbox layer and sent out, then sits | at scmi_wait_for_message_response() with a timeout of 30ms | 1ms: Message #1 is queued in mailbox layer but not sent out yet. | Since send_message() doesn't block, it also sits at | scmi_wait_for_message_response() with a timeout of 30ms | ... | 25ms: Message #0 is completed, txdone is called and message #1 is sent | 31ms: Message #1 times out since the count started at 1ms. Even though | it has only been inflight for 6ms. Fixes: 5c8a47a5a91d ("firmware: arm_scmi: Make scmi core independent of the transport type") Signed-off-by: Justin Chen Message-Id: <20241014160717.1678953-1-justin.chen@broadcom.com> Reviewed-by: Cristian Marussi Tested-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Give SMC transport precedence over mailbox

2024-10-11T15:52:42Z

Broadcom STB platforms have for historical reasons included both "arm,scmi-smc" and "arm,scmi" in their SCMI Device Tree node compatible string, in that order. After the commit b53515fa177c ("firmware: arm_scmi: Make MBOX transport a standalone driver") and with a kernel configuration that enables both the SMC and the mailbox transports, we would probe the mailbox transport, but fail to complete since we would not have a mailbox driver available. With each SCMI transport being a platform driver with its own set of compatible strings to match, rather than an unique platform driver entry point, we no longer match from most specific to least specific. There is also no simple way for the mailbox driver to return -ENODEV and let another platform driver attempt probing. This leads to a platform with no SCMI provider, therefore all drivers depending upon SCMI resources are put on deferred probe forever. By keeping the SMC transport objects linked first, we can let the platform driver match the compatible string and probe successfully with no adverse effects on platforms using the mailbox transport. This is just the workaround to the issue observed which doesn't have any impact on the other platforms. Fixes: b53515fa177c ("firmware: arm_scmi: Make MBOX transport a standalone driver") Signed-off-by: Florian Fainelli Message-Id: <20241007235413.507860-1-florian.fainelli@broadcom.com> Reviewed-by: Cristian Marussi Signed-off-by: Sudeep Holla