как правильно оформить зависимость модулей ядра?

откуда берется зависимость от micrel в вырезке из modules.dep?

скорей всего какое-то кастомное ядро от кривого вендора - MAC и PHY в общем случае универсальные устройства, а тут из кода одного драйвера вызывается ф-ия из другого.

вендор - Altera, и из micrel.c ничего не экспортируется...

вендор - Altera, и из micrel.c ничего не экспортируется...

если ничего не экспортируется, то посмотри MODULE_SOFTDEP

https://elixir.bootlin.com/linux/v5.2-rc2/source/include/linux/module.h#L167

но в данном случае такая зависимости не должно быть - драйвер MAC должен найти PHY через MDIO динамически

драйвер MAC должен найти PHY через MDIO динамически

в том-то и цель... но сейчас я что-то сделал, что и от micrel'a зависимость пропала %)

не смешно, конечно, но блин!

в том-то и цель

она достигается не жесткой зависимостью модулей, а идентификаторами устройств для которых этот драйвер должен быть использовать

https://elixir.bootlin.com/linux/latest/source/Documentation/networking/phy.r...

иначе будет использован Generic PHY Driver

я так и сделал с самого начала

static struct mdio_device_id __maybe_unused mfe_tbl[] = {                           
      { MFE_PHY_ID_BASE,  0xfffffff0 },                                               
      { 0x0000ffff,       0xffffffff },                                               
      { }                                                                             
};                                                                                  
                                                                                      
MODULE_DEVICE_TABLE(mdio, mfe_tbl);

он «находился» сразу без всяких бубнов

так что происходит - MAC не видит PHY или видит но драйвер не подхватывает и использует generic phy ? У меня был отрицательный опыт с stmmac из ванильного ядра на allwiner a20 - он вообще не загружался с realtek PHY, где-то в probe вылетал. В общем у меня так совпало что два говнища (драйвер stmmac и риэтековский PHY) в одной связке оказались :)

забавно :)))

а я у себя уже грешу на dts-файл... в них я, как выяснилось, полный олень, а Quartus меня пугает %)

так что происходит - MAC не видит PHY или видит но драйвер не подхватывает и использует generic phy ?

сама карточка только в разработке, может и MAC «тормозит»... или я %)

Зависимости модуля строятся на основе использующихся функций других модулей.

ага, и он загрузится если глобальный символ из него сослаться из stmmac, но за такие шалости Линус, в былые времена, «привязывал к позорному столбу» %)

из наблюдений:

в modules.alias есть

alias mdio:????????????0010000101100001000? micrel
alias mdio:1101111110100001100110000100???? myphy

в общем, сделал на следующий день, но забыл отписаться - вдруг кому-нить еще понадобится:
зависимость micrel'a от stmmac искуственная, и как-раз из тех за которые выгоняют из профессии, а про «хочется сделать, чтоб модуль myphy загружался автоматом, без принудительного запихивания», нужно так:

static const struct of_device_id myphy_of_match[] = {                              
    { .compatible = "altr,socfpga-stmmac", },                                       
    { }                                                                             
};

static struct platform_driver __maybe_unused myphy_platform_driver = {
    .driver = {                                                                     
        .name = "myphy",                                                           
        .owner = THIS_MODULE,                                                       
        .of_match_table = myphy_of_match,                                          
    },                                                                              
};

MODULE_DEVICE_TABLE(of, myphy_of_match);