On Thu, Apr 28, 2022 at 3:48 PM Dusty Mabe <email@example.com> wrote:
On 4/28/22 10:27, Ian McInerney wrote:
> On Thu, Apr 28, 2022 at 3:00 AM Dusty Mabe <firstname.lastname@example.org <mailto:email@example.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://firstname.lastname@example.org/ <https://email@example.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) . 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.
Post a Comment