Recentemente, foi desenvolvido um novo kselftest para verificar a sonda do driver em plataformas baseadas em Devicetree. Este trabalho é parte de um esforço contínuo para melhorar a integração do kernel em várias frentes, incluindo a melhoria da qualidade dos testes disponíveis para todos.
Apesar da maioria das funcionalidades de cada plataforma vir dos drivers, que expõem interfaces para permitir que o espaço do usuário interaja com o hardware subjacente, ainda não havia uma maneira estabelecida de detectar regressões em qualquer configuração dos drivers da plataforma. A maioria dos subsistemas no kernel compartilha esse framework comum do driver, então é hora de usá-lo para identificar problemas mais facilmente e de forma genérica.
Um teste autônomo que verifica as sondas do dispositivo já existe, chamado bootrr, e tem sido executado no KernelCI por um tempo. No entanto, foram notados alguns problemas importantes com ele. O maior problema é que ele depende de ABIs instáveis do kernel (especificamente, nomes de dispositivos e drivers), que ocasionalmente mudam de uma versão do kernel para a próxima, resultando em falsas regressões sendo relatadas pelo teste, e exigindo que ele seja atualizado para funcionar de maneira diferente para cada versão do kernel.
Para melhorar a situação, a Collabora trabalhou junto com a comunidade e lançou um novo kselftest upstream. A principal vantagem deste teste é que ele depende do Devicetree, que já é mantido para cada plataforma, para fornecer a lista de dispositivos presentes. Portanto, nenhum esforço adicional é necessário para habilitá-lo em uma nova plataforma ou para mantê-lo compatível com as mudanças no kernel.
O teste funciona iterando sobre os nós na Devicetree atualmente carregada e verificando se há um dispositivo e driver correspondente vinculado a ele através do sysfs. Nem todos os nós Devicetree são esperados para registrar um dispositivo e tê-lo vinculado a um driver, então o teste é capaz de ignorar aqueles com base na lista de compatíveis Devicetree que extrai de todos os drivers na fonte do kernel.
Recentemente, adicionamos este novo teste no KernelCI. Para o Chromebook Tomato baseado em MT8195, por exemplo, você pode ver os resultados para a árvore Linux-next abaixo. Como pode ser visto, há 181 testes passando – dispositivos que foram verificados para terem sido vinculados com sucesso aos drivers; 34 testes ignorados – dispositivos que não têm um driver correspondente no kernel e, portanto, não são verificados; e 11 testes falhando dos quais: 5 são dispositivos que compõem o pipeline de exibição e estão realmente falhando na sonda, mas serão corrigidos assim que este patch pousar; 3 do pipeline de áudio devido a um problema com a configuração de memória DMA no DSP.
