08:02 <mvaittin> mriesch: out of the curiosity - which IC is detecting the over-current situation in your use-case?

08:05 <mriesch> mvaittin: the fault pin of the load switch is routed to a gpio of the application processor

08:07 <mriesch> sending the event seems quite straightforward to me, but i wonder how this looks on the consumer side.

08:08 <mriesch> i would say that the usb2 phy driver could be the consumer of the vbus voltage and react to those events

08:10 <mvaittin> mriesch: Oh, so the load switch is modeled as a regulator - and it generates the IRQ for over-current, which sends the notification. Makes sense to me. So, it means there is only one possible "severity" for this issue - and only one possible recovery-action (disable/re-enable) the consumer can take?

08:11 <mvaittin> Sorry - I have no much help to offer :) I was just curious about the use-case

08:13 <mriesch> mvaittin: yes, there is only one type of error (usually over-current). and only one way to recover.

08:14 <mvaittin> (but for what it is worth - to me your reasoning sounds correct. Yet, I am not in a position to give recommendations/advieces :) )

08:18 <mriesch> well to be honest it is mostly broonie's reasoning (clean division into producer and consumer), i would have come up with a monolithic magic black box that handles the recovery :-)

08:22 <mvaittin> mriesch: Well, I've learned to appreciate the reasoning coming from him (at least when it's aligned with mine XD)

08:25 <mvaittin> At least having the proper regulator-consumer division works as an example for other similar cases. If the recovery is hidden in the regulator it will easily go unnoticed and next one will re-invent the wheel.

08:27 <mriesch> true

09:52 <javierm> geertu: a trivial thing I forgot to mention in your series is that the drm subsystem uses as convention for the subject line "drm/foobar" instead of "drm: foobar"

10:43 <geertu> javierm: Seems to depend. The heuristic I'm using is "drm/foo" for core functionality, "drm: bar:" for drivers?

10:47 <javierm> geertu: I don't think so. As usual there are some inconsistencies but AFAICT most commits use "drm/bar:" even for drivers

10:47 <geertu> javierm: OK, will fix

10:47 <javierm> geertu: thanks

12:59 <mwalle> arnd: do you have any idea how I can proceed with https://lore.kernel.org/lkml/1e46ae6508997c2bb3f1f0c922ae81d8@walle.cc/ ?

13:04 <arnd> mwalle: I would normally expect Li Yang to pick up the patches, or at least review them

13:06 <arnd> I think it's too late for that for 5.18 now, but the next best alternative would be that you resend them after -rc1 is out, and ask shawnguo to pick them up into the imx tree for 5.19

13:40 <marex> sboyd: I sent critical-clocks v2 with even better description

13:55 <mwalle> arnd: ok thanks, will do

15:52 <gpiccoli> Hi folks, does anybody know if Broadcom makes datasheet available somewhere? I'd like to understand more about the AON (Always ON) register, power management domain...

16:00 <jn> gpiccoli: broadcom isn't very good at that, in my experience. however, if you mention the specific chip (family) that you're dealing with, maybe someone has a pointer

16:01 <gpiccoli> o/ jn, thanks! In fact, I'm studying a panic notifier and that code is basically a memory write: writel_relaxed(BRCMSTB_PANIC_MAGIC, ctrl.aon_sram + AON_REG_PANIC);

16:01 <gpiccoli> Seems it's a STB PSCI extension for power management, used in BCM7xxx for example

16:02 <gpiccoli> I'd like to understand what this write does! Is it a PSCI reset ? Some "informative" write only? Zero documentation in the code...