Re: [PATCH 0/5] Exynos850 APM-to-AP mailbox support

[Alexey Klimov]

On Thu Apr 2, 2026 at 7:43 AM BST, Krzysztof Kozlowski wrote:
> On 02/04/2026 04:19, Alexey Klimov wrote:
>> On Sat Mar 21, 2026 at 10:44 AM GMT, Krzysztof Kozlowski wrote:
>>> On Fri, Mar 20, 2026 at 09:15:12PM +0000, Alexey Klimov wrote:
>>>> Hi all,
>>>>
>>>> This patch series introduces support for the APM-to-AP mailbox on the 
>>>> Exynos850 SoC. This mailbox is required for communicating with the APM 
>>>> co-processor using ACPM.
>>>>
>>>> The Exynos850 mailbox operates similarly to the existing gs101 
>>>> implementation, but the register offsets and IRQ mask bits differ. 
>>>> This series abstracts these differences into platform-specific data 
>>>> structures matched via the device tree.
>>>>
>>>> Also, it requires APM-to-AP mailbox clock in CMU_APM block.
>>>>
>>>> In theory this can be split into two series with correct dependecies:
>>>> device tree node requires clock changes to be merged. The suggestion
>>>> is to let this go through Samsung SoC tree with corresponding acks
>>>> if it is okay.
>>>
>>> I don't understand why this cannot be split into two seris
>>> *practically*. What is exactly the dependency between mailbox and DTS,
>>> that it had to be combined here?
>> 
>> Do you suggest to send 3 single patches with proper dependencies
>> description? DT bindings change first, then mailbox change that specifically
>> depends on dt-bindings change and then dts update (which will depend on both)?
>> 
>> I thought that mbox driver change depends implicitly on bindings update?
>
> Please don't answer to a question with a question. Actually three
> questions. If you cannot give argument why there is a dependency, feels
> to me like you send something you do not understand.

Sorry. You're right on the first part. Couldn't say anything about last part.

So I saw series where DTS enablement changes are included in the series
after changes in drivers were introduced. I guess it is more preferred
to split out DTS changes (also considering that kernel without these
changes should be able to boot with new DTS and vice versa). I can split
out DTS change(s), yes. There should/must be no dependency. Thanks.

Best regards,
Alexey