On Tue, Apr 26, 2022 at 9:15 PM Dusty Mabe dustymabe@redhat.com wrote:
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?
This should not be a problem. I am CCing 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.
Justin
Thanks for your advice on this, Dusty
[1] https://www.pine64.org/quartz64a/ [2] https://github.com/archlinuxarm/PKGBUILDs/pull/1918
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?
This should not be a problem. I am CCing 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.
Dusty you should know this process by now!
Peter
On 4/27/22 11:06, Peter Robinson 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?
These were kernel config options so I reached out to Justin for advice. He gave me great advice by pointing me here, where I'll come in the future for requests like this.
In hindsight the config options are related to an ARM device, so it would have been good to start here.
This should not be a problem. I am CCing 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.
That's good news, but the way you delivered the news makes me feel really dumb.
I'm not an expert in these topics and what is obvious to you isn't obvious to me or a lot of people. I was trying to do some due diligence up front for a board I'd like to purchase and run my favorite distribution on. I found where someone running Arch needed these kernel config options set so I asked our resident kernel expert about them.
Dusty you should know this process by now!
Again, thanks for assuming I'm not following the process on purpose or being dumb for not knowing the proper place to go. It makes me feel good to know there's so much support for people who are looking to learn how to contribute and be part of this community.
On Wed, Apr 27, 2022 at 4:06 PM Peter Robinson pbrobinson@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 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) 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, 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.
-Ian
Dusty you should know this process by now!
Peter _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@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
On 4/27/22 12:27, Ian McInerney wrote:
On Wed, Apr 27, 2022 at 4:06 PM Peter Robinson <pbrobinson@gmail.com mailto:pbrobinson@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
On Thu, Apr 28, 2022 at 3:00 AM Dusty Mabe dusty@dustymabe.com wrote:
On 4/27/22 12:27, Ian McInerney wrote:
On Wed, Apr 27, 2022 at 4:06 PM Peter Robinson <pbrobinson@gmail.com
mailto:pbrobinson@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%3E) 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%3E, 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?
That summary makes sense to me, and I think the one that could be done immediately would be setting CONFIG_MMC_SDHCI_OF_DWCMSHC=m, since enabling a new module is probably not controversial.
As for the CONFIG_MOTORCOMM_PHY entry, I did see that there is a device tree currently under review upstream for the Quartz64-B ( https://patchwork.kernel.org/project/linux-rockchip/patch/20220425171344.192...), but it doesn't include any compatibility entry for selecting the motorcomm PHY driver. I haven't experimented with this yet, but I wonder if adding an entry to the device tree would allow the proper driver to be loaded from a module once this device tree is accepted into upstream. I have reached out to the original device tree author (who also contributed the motorcomm driver) to get their thoughts on this. If the device tree entry will work, then it means the motorcomm driver could be built as a module instead.
-Ian
Thanks for the help! Dusty
On 4/28/22 10:27, Ian McInerney wrote:
On Thu, Apr 28, 2022 at 3:00 AM Dusty Mabe <dusty@dustymabe.com mailto:dusty@dustymabe.com> wrote:
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?
That summary makes sense to me, and I think the one that could be done immediately would be setting CONFIG_MMC_SDHCI_OF_DWCMSHC=m, since enabling a new module is probably not controversial.
As for the CONFIG_MOTORCOMM_PHY entry, I did see that there is a device tree currently under review upstream for the Quartz64-B (https://patchwork.kernel.org/project/linux-rockchip/patch/20220425171344.192... https://patchwork.kernel.org/project/linux-rockchip/patch/20220425171344.1924057-6-pgwipeout@gmail.com/), but it doesn't include any compatibility entry for selecting the motorcomm PHY driver. I haven't experimented with this yet, but I wonder if adding an entry to the device tree would allow the proper driver to be loaded from a module once this device tree is accepted into upstream. I have reached out to the original device tree author (who also contributed the motorcomm driver) to get their thoughts on this. If the device tree entry will work, then it means the motorcomm driver could be built as a module instead.
Wow. Big thanks to you for looking at this so closely!
Just one question there. The model I linked to is the A model (Quartz64-A) [1][2]. Not sure if looking at the device tree for B is equivalent or not.
Dusty
On Thu, Apr 28, 2022 at 3:48 PM Dusty Mabe dusty@dustymabe.com wrote:
On 4/28/22 10:27, Ian McInerney wrote:
On Thu, Apr 28, 2022 at 3:00 AM Dusty Mabe <dusty@dustymabe.com <mailto:
dusty@dustymabe.com>> wrote:
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?
That summary makes sense to me, and I think the one that could be done
immediately would be setting CONFIG_MMC_SDHCI_OF_DWCMSHC=m, since enabling a new module is probably not controversial.
As for the CONFIG_MOTORCOMM_PHY entry, I did see that there is a device
tree currently under review upstream for the Quartz64-B ( https://patchwork.kernel.org/project/linux-rockchip/patch/20220425171344.192... < https://patchwork.kernel.org/project/linux-rockchip/patch/20220425171344.192...), but it doesn't include any compatibility entry for selecting the motorcomm PHY driver. I haven't experimented with this yet, but I wonder if adding an entry to the device tree would allow the proper driver to be loaded from a module once this device tree is accepted into upstream. I have reached out to the original device tree author (who also contributed the motorcomm driver) to get their thoughts on this. If the device tree entry will work, then it means the motorcomm driver could be built as a module instead.
Wow. Big thanks to you for looking at this so closely!
Just one question there. The model I linked to is the A model (Quartz64-A) [1][2]. Not sure if looking at the device tree for B is equivalent or not.
There is a different device tree for the Quartz64-A, and that is already in the kernel (they say it is included starting with 5.14), but it also doesn't specify the PHY compatibility entry. I think it could be modified in a similar manner to work as well.
-Ian
Dusty
On Wed, Apr 27, 2022 at 11:27 AM Ian McInerney ian.s.mcinerney@ieee.org wrote:
On Wed, Apr 27, 2022 at 4:06 PM Peter Robinson pbrobinson@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?
Agreed, and any changes to the thousands of non arm specific configs would be handled this way (or bugzilla or fedora kernel list). Arm is the exception here, I wouldn't fault anyone for not knowing that.
Justin
This should not be a problem. I am CCing 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) 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, 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.
-Ian
Dusty you should know this process by now!
Peter _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@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
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@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