06:50 <ukleinek> pinchartl: don't know if you're missing something (else), but AFAIK there is no generic DT property to set the voltage of a regulator.

09:21 <ukleinek> bah, _regmap_raw_read isn't just regmap_raw_read without locking :-\

10:10 <javierm> pinchartl: maybe I'm misremembering but I think that asked the same before and the answer was that only the consumer knows that voltage could be safe and that doing an assigned-clock like could be harmful

10:11 <javierm> broonie: ^

10:12 <broonie> pinchartl: set a constraint with the same min/max voltage - we will apply the constraint when registering the regulator

10:32 <broonie> ukleinek: there's bulk_read()

10:49 <pinchartl> broonie: thanks

10:49 <pinchartl> it's a gpio regulator

10:50 <pinchartl> so I didn't think about using the min/max constraints to select the voltage, but that makes sense

10:50 <pinchartl> should have thought about it :-)

13:31 <ukleinek> broonie: yup, but no variant that doesn't take a lock, and to implement that I need a variant of regmap_raw_read that doesn't take a lock.

13:35 <oldgalileo> I'm having a hard time understanding the Kernel / OP-TEE calling conventions, specifically for RPC requests.

13:35 <oldgalileo> Looking at the documentation here https://github.com/OP-TEE/optee_os/blob/9b1d1cf0d63381c6d6a4d95ca2ac040834ad39e5/core/arch/arm/include/sm/optee_smc.h#L682 it looks like the SMC return args are not intended to be used (specifically `a1-2`)

13:36 <oldgalileo> And that instead the `optee_msg_arg` should be at the location represented by the "shared memory cookie"

13:37 <oldgalileo> In `drivers/tee/optee/rpc.c#L532` (https://elixir.bootlin.com/linux/v5.10.104/source/drivers/tee/optee/rpc.c#L532), it uses the `a1-2` registers to build the address to the shared memory. Is that risky behavior that's not guaranteed to be correct?

13:39 <oldgalileo> And a follow-up: If you follow the linked code above and go through to the subsequent `handle_rpc_func_cmd` call, it sets up the `optee_msg_arg` through the virtual address instead of the physical address. Why is there a switch if you call and provide the physical address? (Apologies if this is a very basic memory question)

13:42 <broonie> ukleinek: Why do you need something lockless here? In general regmap is going to do some locking.

13:44 <ukleinek> broonie: I implemented a regmap_bulk_update_bits_base() to be used in pca953x_gpio_set_multiple()

13:45 <ukleinek> broonie: to implement that I need to do: lock(); _regmap_bulk_read(); update(the bitmask); _regmap_bulk_write(); unlock()

13:46 <ukleinek> So _regmap_bulk_read() and _regmap_bulk_write() must not take the lock

13:55 <broonie> So you need to push the lock down and make the existing functions wrappers.

14:03 <ukleinek> broonie: not sure I understand your statement. Here is my WIP: https://paste.debian.net/hidden/2326f6b3/

14:11 <broonie> ukleinek: look at how the other paths do internal/external use paths.

14:16 <ukleinek> broonie: ??

14:19 <broonie> ukleinek: Copy what's done so we can implement regmap_update_bits() and other things that do mutliple ops.

14:20 <ukleinek> I took a mixture of regmap_update_bits and regmap_bulk_read/write as a template

15:29 <oldgalileo> After reading more about the OP-TEE SMC call I'm still lost as to how this works in the Kernel. It seems like this line: https://elixir.bootlin.com/linux/v5.10.104/source/drivers/tee/optee/rpc.c#L532 shouldn't work?

15:32 <oldgalileo> Sorry, to be more specific: with my current understanding it seems like it shouldn't work consistently? I'm making an RPC call to OP-TEE. I have registered my SHM, and I have the virtual address of my message arguments in the shared memory.

15:35 <oldgalileo> I get the physical address of the message arguments and I make an SMC call, providing the physical address. OP-TEE does some work on a thread, then returns, then I resume and now the SMC return registers are populated with values from OP-TEE.

15:41 <oldgalileo> At this point, I get lost. It looks like we're getting back the same physical address to the message args inside the shared memory that we provided at the SMC call time? And then we're blindly using that returned physical address to get back to the shared memory?

15:41 <broonie> oldgalileo: It would probably better to post to the list CC the OP-TEE maintainers.

15:43 <oldgalileo> broonie: Fair. I think heat told me to as well. I just feel bad wasting people's time. I'm sure that the Linux kernel implementation **isn't** the issue here, but I think this detail is crucial to understanding an issue an EDK2 implementation

15:43 <broonie> oldgalileo: You're more likely to get someone who knows the OP-TEE code there.

16:05 <oldgalileo> Just found out that there's an official TrustedFirmware Discord server (:sob:) so I may try my luck there before hitting the mailing list. Thanks for the recommendation

16:22 <Xogium> trusted firmware... On discord. What has the world come to ?

17:25 <broonie> Everything is on discord these days. One of the reasons I never look at discord is the amount of things that get you signed up for some entire server.

17:32 <conchuod> Without a proper account switcher it is also a pain in the arse.

17:33 <conchuod> I don't want my profile on <insert random programming discord> showing what my steam is or that I am listen to taylor switft, yaknow?

18:25 <ukleinek> broonie: my modification works now. I still fail to understand however what you want to tell me about my wip change.

18:26 <broonie> ukleinek: That was a general comment about how things should look rather than specifically about your change.

18:27 <ukleinek> broonie: ok, then I think I'm on the right track. Will cleanup and put into nice patches next week then.