On Thu, Apr 28, 2022 at 3:48 PM Dusty Mabe <dusty(a)dustymabe.com> wrote:
On 4/28/22 10:27, Ian McInerney wrote:
> On Thu, Apr 28, 2022 at 3:00 AM Dusty Mabe <dusty(a)dustymabe.com <mailto:
dusty(a)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....
<
https://patchwork.kernel.org/project/linux-rockchip/patch/20220425171344....>),
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