06:52 <Ke> people who are using mwifiex_pcie with samsung chromebook plus and GNU/Linux, which firmware blob are you guys using

06:53 <Ke> I use one from firmware-libertas, just thinking whether using the one from chromeos or something would be helpful

08:03 <maz> Ke: I'm using the one from ChromeOS. the one packaged as part of the Debian package didn't work for me. But even with that, I found the driver to be rather flaky if changing access-points frequently.

08:04 <Ke> did not work at all?

08:04 <maz> Ke: I end-up unbinding/rebinding the device each time I switch from one SSID to another.

08:04 <maz> Ke: nope.

08:06 <maz> Ke: I remember testing that at work, and we have a pretty complicated wifi setup here (PEAP+MSCHAP+certificates and crap...)

08:07 <maz> maybe it would work in a simpler setup.

08:52 <Ke> maz: perhaps, I have no idea, what is done by the drivers, hw or the userland config utilities

12:37 <maz> mmind00: have you noticed that the serial console doesn't survive a suspend-resume on kevin? or is it just me?

12:45 <eballetbo> maz: hmm, works here

12:47 <maz> eballetbo: interesting. could be a consequence of my configuration...

12:48 <maz> eballetbo: is your serial port over a servo board?

12:59 <mmind00> maz: I don't test suspend-resume often enough, but on past-tries, I don't remember the serial console failing on the kevin in my boardfarm

13:09 <maz> mmind00: I can manage to get nonsense on the line, but it looks like the baud-rate is screwed. On the other hand, this is a rev-4 kevin, the one that is stuck with a firmware from 2 years ago. my other board doesn't have the servo connector, so I cannot test with that one.

13:22 <Ke> where can I get that revision btw?

13:30 <maz> Ke: I'm not sure there is an easy way to extract the information., other than providing multiple DTs in the ITS file, each with a different version number, and see what coreboot picks up.

13:30 <Ke> is it written on the board?

13:30 <maz> Ke: don't think so.

13:49 <eballetbo> maz: yes, it is over servo board

15:30 <eballetbo> mmind00: I've a patch ready to send that removes some type-c properties from the rk3399.dtsi because now are not required. There is any policy regarding the compatibility between new dt files with old kernel that I should take in consideration? Or it is fine to send?

17:05 <mmind00> eballetbo: there are different "schools of thought" for that ;-) ... new kernel+old dt is a given ... but considering that the whole typec stuff only works like recently, I guess that change should be also fine