09:11 <mrutland> HdkR: I have further patches to migrate more of the entry code to C that I'm planning to post around v5.14-rc1, which should move the remainder of the ret_to_user triage logic to C

09:11 <HdkR> Cool

09:11 <mrutland> HdkR: It'll still be a big chunk of work to migrate to the common entry code, since there are some pretty major differences between the way arm64 and x86 handle some things, but once it's all in C it'll be much easier to see the wood for the trees

09:14 <HdkR> I'm looking forward to it

15:05 <sudeepholla> arnd, is arm soc PR for v5.14 not yet sent to Linus ? or am I missing to find it ?

15:07 <arnd> I haven't seen it either. Since olofj did the merges this time around, he would be the one to send the pull requests as well

15:08 <sudeepholla> arnd, oh ok, thanks

15:24 <geertu> arnd: Do you know who will handle the fixes for rc2?

15:31 <arnd> geertu: no, we haven't discussed this yet, just send it soc@kernel.org cc both of us when you have something urgent

15:36 <geertu> arnd: Ok thx. Will send after rc1, due to cross-subsystem dependencies

20:51 <ukleinek> broonie: I experience a strange problem on a system using drivers/spi/spi-imx.c, GPIOs as CS and drivers/iio/adc/ti-ads7950.c

20:52 <ukleinek> broonie: when I trigger reading the channels using iio magic I get the following trace: https://paste.debian.net/hidden/e815edb6/

20:54 <ukleinek> broonie: the wrong thing is that the CS isn't deasserted at the end. I noticed that drivers/iio/adc/ti-ads7950.c makes use of .cs_change, but I don't understood the semantics (and the logic in that driver) enough to judge if the spi-imx driver is wrong or if it's ti-ads7950. Can you assist?

20:55 <broonie> If cs_change is set in the last transfer the cs should be left exactly as it was at the end.

20:55 <ukleinek> does cs_change matter for the non-last transfers?

20:55 <broonie> Otherwise it should trigger an immediate change at the end of the transfer

20:56 <ukleinek> maybe the driver intended to skip the deassert+assert in between these transfers?!

20:58 <broonie> Perhaps. In general it’s a bad idea and prone to adapting to controller bugs but that is what it’s supposed to be for.

21:00 <ukleinek> broonie: so .cs_change doesn't matter for non-last transfers, right?

21:01 <mkl_> ukleinek: cs_change basically tells the spi-core to do the opposite of the default

21:02 <mkl_> ukleinek: by default on the last transfer the cs is de-asserted - with cs_change = true it's kept active

21:02 <broonie> The driver is probably using cs_change to issue what would normally be a sequence of messages in a single message for performance reasons.

21:03 <mkl_> ukleinek: between transfers of a single message by default the CS is kept active - with cs_change = true it's toggled

21:04 <broonie> Historically this could sometimes perform better than issuing a bunch of async transfers.

21:06 <broonie> These days a lot more performance stuff factored out into the core so it’s less likely to be a substantial win, but obviously it might still work out well

21:10 <ukleinek> mkl_, broonie: ok, with that in mind I will continue to debug that tomorrow. Thanks.