11:07 <pinchartl> what's a typical workflow for CI on merge requests, when testing on real hardware ? my understanding is that a merge request from a fork runs the pipeline in the fork (otherwise it could steal secrets and do lots of bad things). do maintainers of the parent project need to manual trigger a pipeline run after reviewing the merge request to make sure it doesn't contain malicious code ?

11:10 <pinchartl> and does this also mean that I should consider all variables defined in the project's configuration to be readable by any user who has permission to run pipelines ?

11:57 <ishitatsuyuki> pinchartl: only trusted developers will be able to run CI anyway, even for forks. drive-by contributors will need to ask someone to run CI for them

11:57 <ishitatsuyuki> https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/540

11:58 <ishitatsuyuki> I believe if you trigger a "Merge Request Pipeline", it runs with the secrets of the main project

11:58 <pinchartl> thanks for the link

11:59 <pinchartl> my understanding is that a developer trusted by gitlab.fd.o will be able to use the standard runners in their fork

11:59 <pinchartl> but their fork won't contain the secrets of the parent project

12:00 <ishitatsuyuki> yes

12:00 <pinchartl> so the jobs in the forked .gitlab-ci.yml that depend on those secrets (such as submitting test jobs to a LAVA farm for instance) won't run successfully

12:00 <ishitatsuyuki> i think you are right

12:00 <pinchartl> while developers trusted by the parent project will be allowed to run pipelines in the parent project, accessing the secrets

12:01 <pinchartl> which means that any such trusted developer could see the secret variables

12:01 <ishitatsuyuki> I guess yes

12:01 <ishitatsuyuki> but I don't think secrets are dumped by default and they will need to explicitly push a malicious commit to dump it

12:02 <pinchartl> I need to study the permission model in more details. obviously gitlab users who are maintainers of the parent project can access the variables in the gitlab UI, but I wonder how users who are granted developer membership will be treated

12:03 <pinchartl> yes, they would need to push a malicious commit to a test branch and run the pipeline on it

13:07 <colinmarc> hi, I am trying to create a gitlab.freedesktop.org account to submit a patch to mesa, but the confirmation never sent (email: hi@colinmarc.com; I signed up an hour ago). I clicked the resend button a few times in that time. Sorry if this is the wrong channel to ask about this issue.

13:16 <DavidHeidelberg> colinmarc: Heya! Nice to see new Mesa contributor. Don't worry, it takes some time, but you get confirmation (I guess no later than on Monday)

13:18 <colinmarc> oh ok, thanks!

14:18 <lumag> mupuf: I stumbled upon unpredictable delays between turning 220V off and the PSU capacitors actually being drained enough to power off the device (especially if the device is in some low-power state).

14:19 <lumag> So my definite vote is for cutting 12V / 5V via the relay instead of 220V.

14:21 <lumag> But this way I end up with the mess of wires

14:28 <pinchartl> lumag: I'm increasingly thinking that, for USB-powered devices, something similar to https://www.mikroe.com/usb-c-source-click

14:28 <pinchartl> I "just" need to make a base board that will have some kind of connectivity to the LAVA worker

14:28 <lumag> Heh

14:29 <pinchartl> maybe over CAN, that's a relatively good middle ground between complexity and reliability

14:29 <lumag> Yes, relays can not hand

14:29 <lumag> handle USB-PD, that's true

14:31 <pinchartl> in a perfect world, STUSB4700 would have current measurement capabilities

14:31 <pinchartl> to measure the power consumption

14:38 <lumag> pinchartl, measuring resistor + I2C ADC?

14:38 <pinchartl> I'd have to redesign the usb-c-source

14:39 <pinchartl> in which case I could as well add the µC directly to the board

14:39 <pinchartl> and add a few GPIOs, they're always useful

14:39 <mupuf> lumag: yes, that indeed sucks. I had to use 30s of power off time to combat that

14:39 <pinchartl> and ...

14:39 <pinchartl> and it will end up being yet another overdesigned project :-)

14:40 <mupuf> But we can hide this latency most of the times

14:40 <lumag> pinchartl, :-D

14:40 <mupuf> pinchartl: he he, yeah

14:40 <mupuf> And don't forget to add an FTDI too :p

14:41 <pinchartl> of course

14:41 <pinchartl> I *really* wish all development boards were as nice as https://ologicinc.com/portfolio/mediatek-pumpkin-i350/ when it comes to testing

14:41 <mupuf> I keep thinking about making a PCB like this... But it always feels like too much

14:41 <pinchartl> the USB-to-UART chip on that board has host-controllable GPIOs connected to the reset signal, the power on signal, and the boot mode selection signal

14:42 <pinchartl> I want the same everywhere

14:42 <pinchartl> it's sooooooo nice to use

14:42 <pinchartl> you can control power and reflash everything, including a bricked boot loader, without any external equipment nor manual intervention

14:42 <lumag> heh. 96boards uart mezz had ability to reset the board IIRC

14:43 <lumag> But 96b is mostly dead

14:43 <mupuf> Asahi made something like that already

14:44 <pinchartl> given the amount of people who need to perform automated testing, why can't we pool resources and create something that would be reasonably cheap to manufacture ?

14:45 <mupuf> The issue is that if we want to support all kind of boards, we'll end up building a monster PCB :D

14:46 <lumag> mupuf, IMO, detachable FTDI might be better. e.g. most of the boards that I care about have onboard FTDI. But then we loose FTDI GPIO.

14:47 <pinchartl> mupuf: that's why I think this should be a 80/20 project. 20% of the effort and cost to cover 80% of the use cases

14:47 <lumag> and don't forget that the board ideally should be sourced from PoE

14:47 <pinchartl> I would give it an external 24V power

14:48 <pinchartl> that will allow high power USB PD

14:48 <pinchartl> it's easily available

14:48 <pinchartl> solving just the USB power problem should be reasonably cheap

14:48 <pinchartl> and that would help a lot

14:49 <lumag> PoE is 48V

14:49 <pinchartl> yes, but more hardware

14:49 <lumag> and it remove 90% of the cabling

14:49 <lumag> Yes. And the price goes to the sky

14:49 <pinchartl> I'd go for CAN for the control interface. easy cabling, the devices can be daisy-chained, and easy to program in a small µC

14:50 <lumag> Even css610-8p-2s is $230

14:50 <pinchartl> POE makes a lot of sense for https://www.linux-automation.com/en/products/lxa-tac.html

14:50 <lumag> is CAN opto-isp;ated

14:50 <lumag> isolated?

14:51 <pinchartl> lumag: https://www.ti.com/lit/an/slla484a/slla484a.pdf?ts=1702219877974&ref_url=https%253A%252F%252Fwww.google.com%252F

14:51 <pinchartl> "How to Design an Isolated CAN Port for Space

14:51 <pinchartl> Constrained Industrial Applications"

14:52 <pinchartl> RS422 could also be an option

14:53 <pinchartl> sorry, RS485

14:54 <lumag> Anyway, both CAN and RS485 will require some configuration, won't they?

14:55 <mupuf> We need HDMI IN too, 8k compatible!

14:55 <lumag> I mean you can not just plug the new controller. It should be addressable

14:55 <lumag> mupuf, no!

14:55 <mupuf> :D

14:56 <lumag> I ordered tesmart 16-port switch. I would like to try it out

14:56 <lumag> Other solutions are mostly crap or cost a lot

14:56 <mupuf> lumag: cool!

14:56 <pinchartl> lumag: correct, but that's doable relatively easily. make all devices reply to a broadcast address, with a protocol to set the device address

14:57 <lumag> This starts to look like WiFi or 802.15.4 over the wire

14:58 <mupuf> The problem with buses is what happens when one connection gets broken, you lose many devices

14:58 <lumag> like old 10base2 eth

14:58 <mupuf> Maybe it makes sense if the PCB is panelized and seccable

14:58 <lumag> Thank you, I had that in the physical lab in my school times

14:59 <mupuf> This way, you could add ports to your PDU by just soldering more ports

15:00 <lumag> mupuf, I'd toss another feature into the list: USB-C switch. Ideally we should be able to switch between basic USB-PD + USB passthrough to the host and another USB-C device attached to the dongle.

15:01 <lumag> So that we can test USB-C altmodes

15:01 <pinchartl> lumag: that's not 80/20 anymore :-)

15:02 <lumag> Yep :-(

15:02 <mupuf> Why have USB-PD though?

15:02 <lumag> I think that was pinchartl's requirement?

15:02 <mupuf> Why not just cutting the power and data pins?

15:03 <lumag> And SBU, and CC?

15:04 <pinchartl> mupuf: because lots of dev boards are nowadays using USB for power, and they consume more than 500mA

15:05 <pinchartl> some work fine with a dumb USB power block that delivers a few amps with USB-PD

15:05 <pinchartl> but others don't

15:05 <pinchartl> so it's a mess

15:06 <mupuf> Of course, but I meant to say that we could just cut the power/data pins

15:08 <lumag> mupuf, and pass through the external power supply?

15:09 <lumag> this means more and more cabling for single DUT

15:12 <mupuf> lumag: yes, and yes

15:22 <lumag> well. having external supply + stusb4761 sounds like a better solution.

15:36 <mupuf> Will need to look into it :)

19:47 <daniels> mupuf: I’ve asked Doug from our team about PD switches - he’s apparently found a good one

19:52 <mupuf> daniels: sweet! Let us know when you get the model name :) Thanks!