On 4/27/22 12:27, Ian McInerney wrote: > On Wed, Apr 27, 2022 at 4:06 PM Peter Robinson <pbrobin...@gmail.com > <mailto:pbrobin...@gmail.com>> wrote: > > Hey Dusty, > > > > Hey jforbes, > > > > > > I'm looking at buying a quartz64 ARM board (relatively new board > > > from pine64 kind of like a Raspberry Pi) [1]. I think there are > > > some config options in the kernel that need to be set. I found where > > > someone opened a PR for Arch [2]. I compared that with what we have > > > in the Fedora aarch64 kernel config and here's what would need to > change: > > > > > > CONFIG_MMC_SDHCI_OF_DWCMSHC is not set -> y > > > CONFIG_MOTORCOMM_PHY=m -> y > > > > > > Is changing kernel config options a big ask or a reasonable request? > > Is it a big ask? No, is it a reasonable request? No. > > These are arm devices so please come to the arm list/maintainers with > these requests? > > > IMO asking Justin was a perfectly valid start to exploring these options, > because he is the Fedora kernel maintainer. And Justin reached out to this > list to solicit input and opinions, so was there really any harm done? > > > > > This should not be a problem. I am CCing arm@lists.fedoraproject.org > <mailto:arm@lists.fedoraproject.org> > > so that others are aware. I will try to remember for 5.17.5 tomorrow, > > but on vacation travelling by motorcycle this week, so if I forget, > > remind me early next week. > > Why do they need to be built in? They don't. One is a SDHCI driver and > the other is an ethernet PHY, both are dealt with in initrd just fine > and have no reason to be built in, we deal with these just fine across > 100s of other devices in initrd. > > > Link [2] provided in the initial email forwarded to the list says that module > loading for the motorcomm PHY does not work because the chip has a zeroed out > manufacturer ID and so it gets associated to the generic driver first and > then can't be associated with the proper driver later. Moving the driver from > a module to being built into the kernel is mentioned under the > troubleshooting section of the Pine64 wiki > (https://wiki.pine64.org/wiki/Quartz64#No_Ethernet_Connectivity > <https://wiki.pine64.org/wiki/Quartz64#No_Ethernet_Connectivity>) as being > the fix for this issue. > > Looking at the driver history, it was noted that the OUI is empty during the > initial driver review https://lkml.org/lkml/2021/5/14/522 > <https://lkml.org/lkml/2021/5/14/522>, and nothing further was noted other > than the possibility of an OUI conflict. So this appears to be needed to fix > a quirk in the hardware where motorcomm didn't include their OUI even though > they were assigned one. > > That being said, I am not sure what the likelihood of a conflict with another > PHY reporting the same (empty) OUI part would be, and so I am not sure if > this would usurp the generic driver in any cases it shouldn't if it were to > be built into the kernel instead of as a module. > > As for the other config (CONFIG_MMC_SDHCI_OF_DWCMSHC), there is no note about > if it needs to be a module or built-in, so it can probably be loaded by the > Quartz64 as a module. The original requester probably suggested it as a > built-in because that is what the other enablement PR in the other distro did.
Thanks Ian. From your evaluation does it look like the following is true: CONFIG_MOTORCOMM_PHY=m -> y - might be needed for this specific hardware but we don't know if it's safe to do. CONFIG_MMC_SDHCI_OF_DWCMSHC needs to be set and having it be a loadable module should be fine? Thanks for the help! Dusty _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
