09:30 <mripard> sboyd: thanks :)

12:29 <ajb-lina-> arnd: I'm resurrecting the rpmb linux driver - you mentioned moving it to its own subsystem (drivers/rpmb) - should the same go for the character interface?

12:30 <arnd> ajb-lina-: I don't remember the details of the debate, but if I suggested making a separate subsystem that would imply having the chardev interface in the same directory as the drivers

13:08 <ajb-lina-> arnd: ack

15:42 <ajb-lina-> arnd: I guess nothing under tools ever builds in an out-of-tree build?

15:42 <arnd> ajb-lina-: I think it is supposed to be possible to copy all of linux/tools into a separate location and build it there

15:43 <arnd> we have a separate copy of a lot of the kernel headers in tools/include/ to make that work

17:37 <ajb-lina-> arnd: how icky is re-using the input buffer passed in an ioctl for the response frame if there is one?

17:43 <arnd> ajb-lina-: the ioctl command code encodes the direction bits for the structure passed as the ioctl argument, which can be read, write or both.

17:44 <arnd> but a structure that you pass only from user to kernel space can contain pointers to other data that gets written back by the kernel, that is not too unusual

17:45 <ajb-lina-> yeah I have #define RPMB_IOC_PKEY_CMD _IORW(0xB8, 82, struct rpmb_ioc_pkey_cmd)

17:45 <arnd> having the kernel write to the structure passed from user space as read-only would be rather unusual, though there is nothing preventing you from doing it other than bad taste

17:47 <ajb-lina-> arnd: hmm I guess some weird ass HW might be invented where the response frame is bigger than the request

18:33 <tlwoerner> is there a way, on a running ARM system, to investigate low-level RAM information such as, say, which regions were being accessed via which controllers?

19:00 <arnd> ajb-lina-: if all data is exchanged inside of the rpmb_ioc_pkey_cmd structure, and new hardware needs a larger struct, that would imply using a new command code

19:02 <arnd> tlwoerner: if the firmware provides numa information, 'numactl -H' should tell you about it in abstract terms, but this is usually not the case. If you have access to /dev/mem, you can do a timing analysis to try to reverse engineer the topology, but that is probably also not what you want

19:40 <marex> sboyd: regarding https://patchwork.kernel.org/project/linux-clk/patch/20220213173310.152230-2-marex@denx.de/#24743652 , what do you mean by 'Use clk_parent_data please.' ?

19:42 <marex> seems like a lot of renesas clock products popped up since they bought IDT