One thing that's bugging me about #Linux kernel code is that variable declarations seem to only occur at start of function or occasionally block. I can't find anything about it in the coding style document. bool is an alias for C99 _Bool, so it can't be ancient compilers that didn't understand declarations in other places. Can anyone explain?

@airtower Tradition. At the time CodingStyle was written, compilers would not allow them elsewhere. Some parts of kernel even sort variable declarations by size.

@pavel I see, so it's people sticking to what they saw in existing code if if it isn't formally required. Is it an unwritten rule now, or could new code declare variables wherever and still get merged?

@airtower I'd say stick to it. Or try our new Rust layer, I'm sure declarations in the middle of code are welcome there :-).

@airtower @pavel The lift up from gnu89 to gnu99 to gnu11 actually happened surprisingly recently in the kernel. So a lot of code was also just written before that was allowed.
From memory what finally tipped someone to do it was the ability to define variables in macros.
New code seems to use the various "new" constructs pretty liberally.

@pavel Definitely something I'm curious about, but right now creating Rust bindings for sdio, mac80211, and rtw88 before I can even get really started would probably delay rtw8723cs a bit much. 😸

@airtower I see you are basing your code on pmos-6.7 tree. Is there 6.8-rc0 based tree for pinephone somewhere?

@airtower @pavel
Found the article on it:
https://lwn.net/Articles/885941/

2022 actually, so yeah very recent

@nota @pavel Huh, fascinating, I wouldn't have expected it do be that recent, and the reason is interesting, too. Thank you! ​

@pavel Not that I'm aware of. My pmos-6.7 tree is just megi's orange-pi-6.7 plus the patches from the pmOS linux-postmarketos-allwinner package.

I haven't tried booting a pure mainline kernel yet (the pmOS wiki indicates it should be possible, without details), if you try that I'd be curious about the results. I wanted to focus on the wifi driver before possibly getting into other issues, when that works it'll remove a big chunk of the diff to mainline already.

@airtower @pavel I can confirm that the mainline kernel boots, but I haven't tried to do much besides run a shell over the serial console. That gives me an idea, I should start working on an overview of the status of the mainline kernel on the PinePhone.

@aren @pavel Such an overview would be really helpful! Was that serial console over headphone plug, or USB-C?

@airtower @pavel That's over the headphone jack. USB gadget mode is not functional without the anx7688 driver, which also depends on changes to the axp803 usb power driver. I'm hoping to post the axp803 patches to the lkml in the next couple weeks, but anx7688 will take longer. It was written specifically for the pinephone, and I'm not sure how much effort it'll take to get it to upstream code standards.

@aren @airtower Yep, that would be very cool :-). Hopefully we'll have useful phone with fully open kernel one day.

@airtower @pavel I started an outline with the information I know off the top of my head, I'll fill in the details as I have motivation / time. I plan to include the status, links to out of tree source, and links to patches that were sent to the lkml. Is there anything else that would be useful to have? https://wiki.pine64.org/wiki/User:Aren/PinePhone_Mainline_Status

@aren @airtower Nice :-). Front camera driver should be upstream in 6.8-rc1, but will need testing and dts parts to activate.

@aren @pavel Thank you! Nothing comes to mind right now at least. Makes me wonder if I should put status and notes for #rtw8723cs somewhere.

@aren @pavel Oh dear, that goes much deeper than no wifi… Thanks for working on it!

@airtower @pavel only if it helps you think :D

I've had this list kicking around my head and scattered notes for a while, but haven't done much with it. I'm hoping that a complete accounting of required patches will make it possible to run a kernel that's much closer to mainline.

@aren @pavel Yeah, definitely, also a good priority list for upstreaming. ​

For the #rtw8723cs status and I was mostly thinking about overview (what's done, what needs doing, known issues), and things I found out about the chip that are too long or uncertain to leave in code comments. Kinda still hoping I can get more people involved, but don't let that distract you from the USB stuff. 😉

@airtower @aren You are doing too good job for people to want to help :-). You'll get testing/review when you have something working, but for now, it is likely you vs. crazy vendor code.