Eu pensei, talvez isso não seja difícil de fazer. E ele começou a trabalhar. Erros de compilação apareceram. Por exemplo, não há função get_ds. Bem, sim, estava na versão 4 do kernel, mas na versão 5 essa função não é. Às vezes penso que os desenvolvedores não querem oferecer suporte a seus drivers devido ao fato de que eles constantemente fazem alterações no kernel e algumas partes do código precisam ser reescritas. Em geral, observei como get_ds é implementado na versão antiga do kernel. Acontece que ele apenas retorna KERNEL_DS. Bem, eu também o substituí. Então houve um problema com a estrutura de tempo, que já tem apenas uma versão de 64 bits no kernel atual. Isso está consertado. Também houve pequenas correções, mas não me lembro o que consertei. Portanto, o driver compilou, mas se recusou a registrar o dispositivo adaptador. Eu encontrei um link de patch, que obriga os fabricantes a especificar as regras. Eu adicionei a cada entrada em os_dep / linux / rtw_cfgvendor.c, este .policy = VENDOR_CMD_RAW_DATA,
Exemplo:
{
{
.vendor_id = OUI_GOOGLE,
.subcmd = RTT_SUBCMD_SET_CONFIG
},
.policy = VENDOR_CMD_RAW_DATA,
.flags = WIPHY_VENDOR_CMD_NEED_WDEV | WIPHY_VENDOR_CMD_NEED_NETDEV,
.doit = rtw_cfgvendor_rtt_set_config
},
{
{
.vendor_id = OUI_GOOGLE,
.subcmd = RTT_SUBCMD_CANCEL_CONFIG
},
.policy = VENDOR_CMD_RAW_DATA,
.flags = WIPHY_VENDOR_CMD_NEED_WDEV | WIPHY_VENDOR_CMD_NEED_NETDEV,
.doit = rtw_cfgvendor_rtt_cancel_config
},
{
{
.vendor_id = OUI_GOOGLE,
.subcmd = RTT_SUBCMD_GETCAPABILITY
},
.policy = VENDOR_CMD_RAW_DATA,
.flags = WIPHY_VENDOR_CMD_NEED_WDEV | WIPHY_VENDOR_CMD_NEED_NETDEV,
.doit = rtw_cfgvendor_rtt_get_capability
},
E compilado, copiado e executado. e voila! Eu consegui. ) Embora eu não entenda o desenvolvimento do kernel, consegui fazer um suporte simples. O link para o código-fonte do driver será postado no disco do google por enquanto. aqui está um link. link .
E agora também está no github .
Fico feliz se for útil para alguém.
