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
<[email protected]> 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
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
