Pensé, tal vez esto no sea difícil de hacer. Y se puso manos a la obra. Aparecieron errores de compilación. Por ejemplo, no existe la función get_ds. Bueno, sí, estaba en la versión 4 del kernel, pero en la versión 5 esta función no. A veces pienso que los desarrolladores no quieren admitir sus controladores debido al hecho de que constantemente realizan cambios en el kernel y algunas partes del código deben reescribirse. En general, miré cómo se implementa get_ds en la versión anterior del kernel. Resulta que solo devuelve KERNEL_DS. Bueno, también lo reemplacé. Luego hubo un problema con la estructura de tiempo, que ya tiene solo una versión de 64 bits en el kernel actual. Esto está arreglado. También hubo pequeños arreglos, pero no recuerdo qué arreglé. Entonces, el controlador compiló pero se negó a registrar el dispositivo adaptador. Encontré un enlace de parche, que obliga a los fabricantes a especificar las reglas. Agregué a cada entrada en os_dep / linux / rtw_cfgvendor.c, este .policy = VENDOR_CMD_RAW_DATA,
Ejemplo:
{
{
.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
},
Y compilado, copiado y ejecutado. ¡y voilá! Me las arreglé. ) Aunque no entiendo el desarrollo del kernel, me las arreglé para hacer un soporte simple. El enlace al código fuente del controlador se publicará en el disco de Google por ahora. aquí hay un enlace. enlace .
Y ahora también está en github .
Me alegro si es útil para alguien.
