Hi,
Tomorrow, Tuesday, it's time for another OP-TEE contributors' monthly
meeting. For time and connection details, see the calendar at
https://www.trustedfirmware.org/meetings/
Maintainers in July:
- Jens is unavailable most or all of July
OP-TEE release July 17:
- Someone needs to fill in for Jens, or we cancel or postpone the release
Next OP-TEE Contributors Forum, July 28
- Can someone else host the meeting, or should we cancel it?
Adding sections in MAINTAINERS
- Core reviewers
- Various TAs
- Updating other parts
Any updates for Kconfig support?
Any other topics?
Cheers,
Jens
Hi Marco,
On Thu, Jun 4, 2026 at 10:57 AM Marco Felsch <m.felsch(a)pengutronix.de> wrote:
>
> Hi Jens,
>
> On 26-05-25, Jens Wiklander wrote:
> > Hi,
> >
> > Tomorrow, Tuesday, it's time for another OP-TEE contributors' monthly
> > meeting. For time and connection details, see the calendar at
> > https://www.trustedfirmware.org/meetings/
>
> Sorry I saw this e-mail to late since I was in Nice last week to attend
> to the Embedded Recipes.
>
> > Regarding Kconfig support:https://github.com/OP-TEE/optee_os/pull/7714
> > It appears that the transition will take quite some time. We'll have a
> > window when some variables have transitioned to be managed by Kconfig,
> > but others remain managed by the makefiles. Do we care that variables
> > passed on the command line may work differently, depending on whether
> > they are managed by makefiles or Kconfig? Can something be done about
> > it?
>
> Could you forward me the outcome of this discussion? I hope to continue
> the work next week, since we _really_ want Kconfig support.
We agreed that the transition may take a couple of years and that we
should try to minimize confusion in the meantime. Until we've
completed the transition, it would be preferable if, from a user
(someone who builds OP-TEE) point of view, it doesn't matter whether a
particular config variable is managed by Kconfig or by Makefiles. At
least when building using the build git. The mindset should be to
avoid causing any problems for the users. Documentation is helpful,
but changing well-established behavior will cause problems.
If the above isn't possible, then my view is that we must plan which
config variables we transition. Then, after each release, we select a
new group of config variables to be merged in a single PR. Or
something like that, so there's some logic behind how different config
variables behave. This will make the transition longer and more
difficult, but that's the price of making incompatible changes.
Cheers,
Jens
Hi,
Tomorrow, Tuesday, it's time for another OP-TEE contributors' monthly
meeting. For time and connection details, see the calendar at
https://www.trustedfirmware.org/meetings/
Regarding Kconfig support:https://github.com/OP-TEE/optee_os/pull/7714
It appears that the transition will take quite some time. We'll have a
window when some variables have transitioned to be managed by Kconfig,
but others remain managed by the makefiles. Do we care that variables
passed on the command line may work differently, depending on whether
they are managed by makefiles or Kconfig? Can something be done about
it?
Any other topics?
Cheers,
Jens
This event has been cancelled.
Linaro Open Discussions monthly meeting
Friday 3 Feb 2023 ⋅ 22:00 – 23:00
China Standard Time - Shanghai
Location
https://linaro-org.zoom.us/j/95682500341https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9568250…
Joyce QI 邀请您参加预先安排的 Zoom 会议。
加入 Zoom 会议
https://linaro-org.zoom.us/j/95682500341
会议号：956 8250 0341
手机一键拨号
+16699009128,,95682500341# 美国 (San Jose)
+13462487799,,95682500341# 美国 (Houston)
根据您的位置拨号
+1 669 900 9128 美国 (San Jose)
+1 346 248 7799 美国 (Houston)
+1 253 215 8782 美国 (Tacoma)
+1 646 558 8656 美国 (New York)
+1 301 715 8592 美国 (Washington DC)
+1 312 626 6799 美国 (Chicago)
888 788 0099 美国 免费
877 853 5247 美国 免费
会议号：956 8250 0341
查找本地号码：https://linaro-org.zoom.us/u/ady2J9Zn7t
Organiser
Joyce Qi
joyce.qi(a)linaro.org
Guests
Joyce Qi- organiser
Mike Holmes
jonathan.cameron(a)huawei.com
lorenzo.pieralisi(a)arm.com
james.morse(a)arm.com
Leonardo Garcia
linaro-open-discussions(a)op-lists.linaro.org
shameerali.kolothum.thodi(a)huawei.com
linux(a)armlinux.org.uk
linaro-open-discussions-request(a)op-lists.linaro.org
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee of the event.
Forwarding this invitation could allow any recipient to send a response to
the organiser, be added to the guest list, invite others regardless of
their own invitation status or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Hi,
Tomorrow, Tuesday, it's time for another LOC monthly meeting. For time
and connection details, see the calendar at
https://www.trustedfirmware.org/meetings/
- OP-TEE version 4.10.0 to be released April 17
- Marco Felsch is working on initial Kconfig support:
https://github.com/OP-TEE/optee_os/pull/7714
+ How to configure? Vanilla "make defconfig" and friends? Should we
support passing "CFG_XXX=y" on the command line for convenience? In a
one-step or two-step operation?
+ Integration with the build git: Do we need a way to ensure the
active configuration matches what the build git expects?
+ Is it possible to make a seamless transition (with no visible
external changes) when building OP-TEE? If so, do we want it?
Any other topics?
Cheers,
Jens
Hi,
Tomorrow, Tuesday, it's time for another LOC monthly meeting. For time
and connection details, see the calendar at
https://www.trustedfirmware.org/meetings/
- Rebased linaro-swg/kernel optee branch on v6.18
Any other topics?
Cheers,
Jens
Hi,
Tomorrow, Tuesday, it's time for another LOC monthly meeting. For time
and connection details, see the calendar at
https://www.trustedfirmware.org/meetings/
I have a couple of small things for the agenda:
- A recent patch [1] on the mailing list proposes to export the OP-TEE
version info printed by the driver during boot in sysfs
- Do we have any questions or issues with the proposed CFG_* variable
improvements from the last LOC?
Are there any other topics?
Please note that the LOC in December will be cancelled.
[1] https://lore.kernel.org/op-tee/20251121141230.489294-1-jj251510319013@gmail…
Cheers,
Jens
Hi,
Tomorrow, Tuesday, it's time for another LOC monthly meeting. For time
and connection details, see the calendar at
https://www.trustedfirmware.org/meetings/
- OP-TEE version 4.8.0 has been released
- We have an op-tee channel at the Trusted Firmware Discord server
[1]. Last week, there was a message about improving the order of all
the config options we have in OP-TEE, the CFG_* variables. In the long
term, we might still aim for Kconfig, but that's quite a large step.
However, there are intermediate steps that we can take. I hope we'll
see more of this.
Are there any other topics?
[1] https://www.trustedfirmware.org/faq/
Cheers,
Jens
Hi Jonathan，all
Are there any items that need to sync during next Tue's LOD meeting？
Thanks
Joyce
> On 26 Mar 2025, at 08:00, linaro-open-discussions-request(a)op-lists.linaro.org wrote:
>
> Send Linaro-open-discussions mailing list submissions to
> linaro-open-discussions(a)op-lists.linaro.org
>
> To subscribe or unsubscribe via email, send a message with subject or
> body 'help' to
> linaro-open-discussions-request(a)op-lists.linaro.org
>
> You can reach the person managing the list at
> linaro-open-discussions-owner(a)op-lists.linaro.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Linaro-open-discussions digest..."
>
> Today's Topics:
>
> 1. About the Device tree handling multiple threads in ARM cpu node LOD discussion(Linaro Open Discussion)
> (Joyce Qi)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 25 Mar 2025 19:24:43 +0800
> From: Joyce Qi <joyce.qi(a)linaro.org>
> Subject: [Linaro-open-discussions] About the Device tree handling
> multiple threads in ARM cpu node LOD discussion(Linaro Open
> Discussion)
> To: Jonathan Cameron <jonathan.cameron(a)huawei.com>
> Cc: Joyce Qi <joyce.qi(a)linaro.org>,
> linaro-open-discussions(a)op-lists.linaro.org, Lorenzo Pieralisi
> <lorenzo.pieralisi(a)linaro.org>, James Morse <james.morse(a)arm.com>, Rob
> Herring <robh(a)kernel.org>, Mark Rutland <mark.rutland(a)arm.com>,
> Alireza Sanaee <alireza.sanaee(a)huawei.com>
> Message-ID: <EB0D6409-56E1-4749-9BCA-26D207EB5DE7(a)linaro.org>
> Content-Type: text/plain; charset=utf-8
>
> Hi Mark, Rob,
>
> https://lore.kernel.org/linux-arm-kernel/20250110161057.445-1-alireza.sanae… to the LoD discussion email list!
> Maybe you have missed the formal email since the title is not so clear:)
>
> Jonathan from Huawei wants to sync the about how to do device tree representation of multi thread cores and resulting shared L1 caches
> In this email list.
>
> Can we discuss here to have a unified solution?
>
>
> https://lore.kernel.org/linux-arm-kernel/20250110161057.445-1-alireza.sanae…
>
>
> Great thanks:)
> Joyce
>
>
>
>
>> On 21 Feb 2025, at 18:07, Jonathan Cameron <jonathan.cameron(a)huawei.com> wrote:
>>
>>
>> Hi Joyce,
>>
>> I'll be in Shenzhen next week but should be able to dial in subject to
>> overcoming a slightly different network.
>>
>> If we can poke the following disconnect that would be very helpful
>> - if it happens on list rather than needing to be discussed on the call
>> that's absolutely fine.
>>
>> It's a difference of opinion between Mark Rutland and Rob Herring
>> (both ARM) about how to do device tree representation of multi thread
>> cores and resulting shared L1 caches. We mostly care about this because
>> we'd like to maintain same level of support in QEMU for ACPI (which has
>> always handled this case) and DT.
>>
>> This was try number 1 based on advice from Rob was to use multiple reg
>> entries in a single cpu node (how the DT spec currently specifies it
>> based on ancient power PC roots)
>>
>> https://lore.kernel.org/linux-arm-kernel/20250110161057.445-1-alireza.sanae…
>> Mark suggested that we just do out of CPU node description as is done for every
>> other level of cache because of the complexity of phandles pointing to the
>> node.
>>
>> Proposal of out of CPU node description. Rob not happy with this one.
>> https://lore.kernel.org/all/20250129164855.676-1-alireza.sanaee@huawei.com/
>> https://lore.kernel.org/all/20250203120527.3534-1-alireza.sanaee@huawei.com/
>>
>> Whilst I'm fairly sure Mark's concerns about references to the CPU node can
>> be resolved with a few minor tweaks (a few properties may become arrays that
>> are index rather than single element) we'd really like to have the two
>> experts engaged in the same thread as so far it's been a case of alternate
>> responses.
>>
>> The other topic that is in my pile is the cache flushing by PA range work.
>> I'm going to be working with our HQ team to ensure the design we put out
>> for that is general enough over the next 2 weeks so we should have something
>> to share after that. The remaining questions prior to posting an RFC are
>> all low level detail things that I don't think would benefit from a discussion
>> until we've shown the code.
>>
>> Final potential topic is MPAM. Particularly if there is anything specific
>> we can do to help with upstreaming.
>>
>> Jonathan
>>
>>
>> Joyce Qi <joyce.qi(a)linaro.org> wrote:
>>
>>> Hi Jonathan, all,
>>>
>>> Happy New Year to all!
>>>
>>> Do we have any topic to sync next week?
>>>
>>> Thanks:)
>>> Joyce
>>>
>>>
>>>
>>>
>>>> On 27 Nov 2024, at 08:00, linaro-open-discussions-request(a)op-lists.linaro.org wrote:
>>>>
>>>> Send Linaro-open-discussions mailing list submissions to
>>>> linaro-open-discussions(a)op-lists.linaro.org
>>>>
>>>> To subscribe or unsubscribe via email, send a message with subject or
>>>> body 'help' to
>>>> linaro-open-discussions-request(a)op-lists.linaro.org
>>>>
>>>> You can reach the person managing the list at
>>>> linaro-open-discussions-owner(a)op-lists.linaro.org
>>>>
>>>> When replying, please edit your Subject line so it is more specific
>>>> than "Re: Contents of Linaro-open-discussions digest..."
>>>>
>>>> Today's Topics:
>>>>
>>>> 1. Re: Flush by PA range Designs. (was Re: Linaro-open-discussions Digest, Vol 38, Issue 14)
>>>> (Joyce Qi)
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>>
>>>> Message: 1
>>>> Date: Tue, 26 Nov 2024 18:36:22 +0800
>>>> From: Joyce Qi <joyce.qi(a)linaro.org>
>>>> Subject: [Linaro-open-discussions] Re: Flush by PA range Designs.
>>>> (was Re: Linaro-open-discussions Digest, Vol 38, Issue 14)
>>>> To: James Morse <james.morse(a)arm.com>
>>>> Cc: Jonathan Cameron <Jonathan.Cameron(a)Huawei.com>, James Morse via
>>>> Linaro-open-discussions <linaro-open-discussions(a)op-lists.linaro.org>,
>>>> linuxarm(a)huawei.com, zengheng4(a)huawei.com, wangyushan12(a)huawei.com,
>>>> Dave Martin <Dave.Martin(a)arm.com>
>>>> Message-ID: <5BF890F5-CE52-4682-AFE6-9FBDE56F2247(a)linaro.org>
>>>> Content-Type: text/plain; charset=utf-8
>>>>
>>>> Hi all，
>>>>
>>>> Will cancel today’s meeting since no special topic today, welcome to contact with when needed.
>>>>
>>>> Thanks
>>>> Joyce
>>>>
>>>>> On 25 Nov 2024, at 21:01, Joyce Qi <joyce.qi(a)linaro.org> wrote:
>>>>>
>>>>> Hi Jonathan，
>>>>>
>>>>> Would you like to continue the MPAM， Flush by PA range Designs or any other topics during tomorrow’s LOD meeting？
>>>>>
>>>>> Thanks
>>>>> Joyce
>>>>>
>>>>>
>>>>>> On 24 Oct 2024, at 00:14, James Morse <james.morse(a)arm.com> wrote:
>>>>>>
>>>>>> Hi guys,
>>>>>>
>>>>>> (CC: +Dave Martin)
>>>>>>
>>>>>> On 10/21/24 15:01, Joyce Qi wrote:
>>>>>>>> On 21 Oct 2024, at 20:50, James Morse <james.morse(a)arm.com> wrote:
>>>>>>>> On 21/10/2024 11:00, Joyce Qi via Linaro-open-discussions wrote:
>>>>>>>>> Thanks a lot for the detailed description and document sharing.
>>>>>>>>> I have uploaded the MPAM materials to the LOD Confluence.
>>>>>>>>>
>>>>>>>>> https://linaro.atlassian.net/wiki/spaces/LOD/overview
>>>>>>
>>>>>>>>> Are you available to join tomorrow’s LoD meeting for the MPAM topics ?
>>>>>>
>>>>>> The code already published for something like the intPARTID proposal is here:
>>>>>> https://git.gitlab.arm.com/linux-arm/linux-dm/-/commits/mpam/partid-pmg-rem…
>>>>>>
>>>>>> The aim was to keep it within the MPAM driver, initially based on some static configuration to prove
>>>>>> its useful before making it more dynamic, probably a mount option.
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> James
>>>>>
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> Subject: Digest Footer
>>>>
>>>> Linaro-open-discussions mailing list -- linaro-open-discussions(a)op-lists.linaro.org
>>>> To unsubscribe send an email to linaro-open-discussions-leave(a)op-lists.linaro.org
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> End of Linaro-open-discussions Digest, Vol 50, Issue 1
>>>> ******************************************************
>>>
>>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> Linaro-open-discussions mailing list -- linaro-open-discussions(a)op-lists.linaro.org
> To unsubscribe send an email to linaro-open-discussions-leave(a)op-lists.linaro.org
>
>
> ------------------------------
>
> End of Linaro-open-discussions Digest, Vol 54, Issue 4
> ******************************************************
