On Wed, Aug 19, 2020 at 02:58:22PM +0200, Krzysztof Kozlowski wrote: > On Wed, Aug 19, 2020 at 02:51:27PM +0200, Lukasz Stelmach wrote: > > Honestly, I don't know and I couldn't find out why. It makes stuff > > work. There has been a commit like this before > > 0f5a751ace25 spi/s3c64xx: Enable GPIO /CS prior to starting hardware > > Apparently, it was lost in > > 0732a9d2a155 spi/s3c64xx: Use core message handling > Then describe at least this... maybe Mark knows why he brough back old > code after refactoring? I'm not sure what's being referred to as being lost in the second commit TBH. The first commit is simple code motion rather than a correctness thing, and more related to the handling of GPIO controlled chip selects according to the description (which people should be using with that controller anyway where possible IIRC, the native chip select has too many assumptions about what it's doing). I don't know that I ever actually used a system that used the native chip select as the actual chip select. Perhaps some quirk was introduced where the chip select signal does something? The commit is also lacking a description of what the issues that are being fixed are.
Attachment:
signature.asc
Description: PGP signature
