07:45 <Xogium> marex: to be fair I didn't have that many problems with this SoC and board. The only thing my defconfig was lacking was optee support, and that was the multi_v7_defconfig. It's just that I failed to spot that tee was enabled but I did something wrong so optee wasn't. Seeed caused me way more trouble than st in this project

07:46 <Xogium> probably helps also that I'm sticking to the st versions of softwares and not going full mainline

08:20 <Xogium> javierm: hello :) I use your awesome interface for finding out what's wrong with defered devices. It did explain for some of them, i.e gave a reason like not ready, but some of them have no reason at all beside their name. What does that mean ?

09:53 <marex> Xogium: I went fully mainline, but then had to backport 484 patches on top of secure optee-os which runs with highest privilege level to make it work at all ... I'm not sure how I feel about it

09:53 <marex> Xogium: I also had to add many kernel patches to get even basic things working

09:54 <marex> Xogium: and uh ... then ... at some point, ST updated the optee-os and tfa release , I updated ... and not even my recovery system kernel booted anymore, because something changed in the optee-os ...

09:55 <marex> I was afraid something like that might happen with such massive firmware depenency ... and it did ... sigh ... so for now, the platform is uninteresting

09:56 <Xogium> marex: I do understand. I'm not saying it's good practice. Just sharing how it has been for me so far

09:56 <marex> the most sad of this all is, that I do not even need or want the extra SBoM components (optee / tfa) for the deployment, they were just unconditionally forced onto me and are useless and harmful, which is real bad

09:56 <marex> with mp15, they were not needed, and with mp13 this was purely a bad decision to enforce it like that

09:57 <Xogium> I have to stick to non mainline at least until the mainline things get improved by st contributions and other folks, because I rely on the low power, suspend to ram and all of those things

09:58 <Xogium> yeah. I don't like the way this was handled, for sure. But for my use of the mp15 I needed to move to tf-a anyway, cause I use barebox bootloader

09:58 <Xogium> and I just honestly didn't feel like building u-boot then barebox so I could get u-boot spl only

10:11 <marex> Xogium: just use u-boot, that provides all the PSCI interface etc.

10:11 <marex> Xogium: as for the contributions, I think that was also blocked by the SCMI stuff, since that was not ready and everything else depended on it, sigh

10:16 <Xogium> marex: tbh I kind of don't like u-boot

10:17 <Xogium> I much prefer barebox ;)

12:46 <Xogium> here's a fun question for y'all. I'm working on the dt and I noticed seeed did what I would presume is a bad thing (they added a &pinctrl section in the dts)

12:46 <Xogium> it has a lot of duplicated labels if you include the base stm32mp13-pinctrl.dtsi

12:47 <Xogium> so I'm removing those (making absolutely sure they are in fact the same pinmux). The problem is i2c1 in seeed and st things doesn't match, and I wonder how I have to deal with this

12:57 <Xogium> same for uart4, interesting

12:58 <Xogium> so how do I deal with different uartand i2c pinmux ?

12:58 <Xogium> *uart and

12:59 <Xogium> should I just rename those nodes and keep the &pinctrl section in my dts ?

13:04 <Xogium> fwiw I just removed about 200 lines of duplicated work from the dts, identical pinmux, and only kept the i2c1, uart4 and usbotg_hs nodes

13:04 <Xogium> but they have duplicate labels too

16:14 <ukleinek> broonie: are spi drivers supposed to call spi_master_suspend() in their remove callback?

16:15 <ukleinek> broonie: context is spi-ti-qspi which returns an error if spi_master_suspend() fails. This might be bad, as some cleanups are skipped then.

16:16 <broonie> ukleinek: not off hand - I’d need to look again but doesn’t sound sensible

16:17 <broonie> That’s almost certainly a bug

16:18 <ukleinek> FTR: That's the only spi platform driver in next that doesn't use .remove_new

16:43 <Xogium> I really can't figure this pinmux thing out... What's one supposed to do when the pinmux for some devices is different on a per-board basis ? Surely not add a &pinctrl section into the dts itself ?

16:43 <Forty-Bot> that's exactly what you do

16:43 <Xogium> really ?

16:44 <Forty-Bot> what else?

16:44 <Xogium> I don't know

16:44 <Xogium> but how do I then avoid duplicate labels ?

16:44 <Forty-Bot> be imaginative

16:44 <Xogium> I included the vendor stm32mp13-pinctrl.dtsi

16:45 <Forty-Bot> you can also /delete-node/ if you are out of ideas

16:45 <Xogium> I'm confused honestly. It wasn't me doing it, seeed did that, and I don't really know how to deal with this. They didn't include the dtsi, they prefered duplicating entire portion of it instead, even the ones that do match the dtsi

16:46 <Xogium> so it kind of confused me

16:46 <Forty-Bot> you can do that too, but it's generally brittler

16:47 <Xogium> yeah and duplicate work's bad

16:47 <ukleinek> Xogium: or use a your-device-b node

16:48 <Xogium> ukleinek: how do you mean ?

16:48 <Xogium> here i2c1 pins are different for example

16:48 <ukleinek> Xogium: than add a &pinctrl { i2c1-a { ... }; }; or something like that

16:49 <Xogium> I see

16:49 <Xogium> this is the first time I see a &pinctrl section in a dts file. I thought these were reserved to dtsi only for some reason

16:49 <Xogium> but it makes sense

16:50 <ukleinek> Xogium: i2c1-1 would be the right name

16:50 <ukleinek> or call it i2c1-local to be sure to not conflict with later additions to stm32mp13-pinctrl.dtsi

16:50 <Xogium> yeah. I just don't want conflict :)

16:51 <Xogium> I'll try that

16:51 <ukleinek> or add i2c1-1 to stm32mp13-pinctrl.dtsi

16:51 <ukleinek> Xogium: &pinctrl is quite usual (for some SoCs more than for others)

16:52 <Xogium> I see

16:52 <Xogium> I wasn't at all sure it was proper given the track record of seeed so far ;)

16:52 <Xogium> thank you both

16:52 <ukleinek> Xogium: i.e. I think every imx dts has an &iomuxc

16:54 <Xogium> right, I see them now

16:55 <Xogium> that's my problem ;) I tend to hyperfocus on what I do and check only this specific SoC vendor

17:26 <Xogium> that's 200 lines less in the dts ;)