mt7621 GPIO mapping mystery

[Daniel Santos]

On 1/22/23 12:24, Arınç ÜNAL wrote:
> On 22.01.2023 20:44, Daniel Santos wrote:
>>
>> On 1/22/23 00:23, Arınç ÜNAL wrote:
>>> On 22 January 2023 02:02:04 GMT+03:00, Daniel Santos 
>>> <daniel.santos at pobox.com> wrote:
>>>> On 1/21/23 15:19, Arınç ÜNAL wrote:
>>>>> On 21.01.2023 21:32, Daniel Santos wrote:
>>>>>> ... You can use this to see what the valid values are for each 
>>>>>> group, because until this all goes yaml, there's nothing to tell 
>>>>>> you if you've used an invalid value.
>>>>> Speaking of which:
>>>>>
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next&id=4e5410668af5475681793df2bb8c7d8dc6f9c327 
>>>>>
>>>>>
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next&id=0c9a567651c3b5d433429da2c7d8e8406ddf1076 
>>>>>
>>>>>
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next&id=b4ac84395820eaa0b99ec56816e53c9386ca8b38 
>>>>>
>>>>>
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next&id=d648fd64e10d9d1609146d0c4e47b0f5988e2a2b 
>>>>>
>>>>>
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next&id=844bca60927f3aae6baafafb1edd218b624254a1 
>>>>>
>>>>>
>>>>> Arınç
>>>> OH FUCK YES!!!  Arınç, you and I are friends now!! :D
>>> Haha hello there!
>>>
>>> Arınç
>>
>> I don't want to spam the group with this, but you have no idea how 
>> much bullshit I've been through that turned out to be a mistake in my 
>> device tree file for which there was no warning about. I almost 
>> re-wrote the ramips arch code over it, but I had to pull myself back 
>> when it was clear that it was unnecessary for my project and hard to 
>> justify billing for it. I have that ADHD thing, so I have to stay on 
>> track.
>
> Glad to read this helps you tremendously. By the way, you didn't CC 
> anyone else so the list didn't receive it ;).
>
>>
>> Anyway, I'm really pleased to see this and it reminds me that I have 
>> a lot of kernel patches I need to submit both to OpenWRT and 
>> upstream, including fixing a command line bug for ramips.
>
> Speaking of fixing stuff, if you take a look at the yaml for mt7620 
> and rt305x, some functions got multiple lists for groups. Like refclk 
> on mt7620. Because mt7620 and mt7628/mt7688 SoCs use the same 
> compatible string, it's impossible to differentiate on the binding 
> which SoC your DT is actually for.
>
> Therefore, the binding will allow all groups listed for that function. 
> For example if your SoC is mt7620, you can only use the refclk 
> function for the mdio group. If you were to put "spi cs1" as the 
> function there, you wouldn't get a warning.
>
> I want to fix this by actually separating mt7628/mt7688 from mt7620 on 
> the pinctrl driver, then split the dt-binding, but I don't know C good 
> enough to do this myself.
>
> I have a lot of things I can actually do right now on my task list 
> which could take more than a year (if nothing new is added on top) to 
> complete, so I'm very slowly learning it. It's also the first 
> programming language I ever attempt to learn so understanding the 
> logic of programming is another challenge I've got to deal with.
>
> I'd appreciate it greatly if you could help me out on this as you seem 
> to know C.
>
> However, I have to send a mail to pinctrl mailing list, see if I can 
> justify breaking the ABI with the maintainers since we would be 
> changing the compatible string for certain SoCs. I've done it once.
>
> Arınç

I'm not at a place where I can take a new project on as I'm going 
through a health problem, but let me know when your ready and I'll see 
if I can help. I'll have to study the code again, as I was mostly 
concerned with fixing my problem before and didn't look much at other 
SoCs. There's a lot of reused code between SoCs and that's not bad 
in-and-of its self, but I'll need to fully analyze them to understand 
where code sharing follows genuine abstractions of the family of 
hardware it represents and which parts are are an improper fusion.

On the flip side, this would spur me to get all of my platform patches 
polished off and sent where they need to go as well!

One thing you'll see a lot in this platform and driver code is code for 
one SoC and a lot of that is because the same internal hardware 
components are reused from one chip to another, and by "internal 
hardware components," I mean devices like a GPIO banks, SPI bus 
controllers, ethernet switches, etc. These are circuits that they can 
essentially copy and paste from one SoC design into another one. Some 
manufacturers will name and version these internal components and have 
separate documentation for them that applies to all of their products 
that contain them, but MediaTek doesn't, so we end up referring back to 
the code for the first SoC where that piece of hardware was used.

Daniel