O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Esta página foi traduzida pela API Cloud Translation.

Monitoramento de ABI do kernel do Android

Você pode usar as ferramentas de monitoramento da interface binária do aplicativo (ABI, na sigla em inglês), disponíveis no Android 11 e versões mais recentes, para estabilizar a ABI no kernel dos kernels do Android. A ferramenta coleta e compara representações de ABI de binários do kernel (vmlinux+ módulos GKI). Essas representações ABI são os arquivos .stg e as listas de símbolos. A interface em que a representação fornece uma visualização é chamada de Interface do módulo do kernel (KMI, na sigla em inglês). Você pode usar as ferramentas para acompanhar e mitigar mudanças no KMI.

As ferramentas de monitoramento de ABI são desenvolvidas no AOSP e usam STG (ou libabigail no Android 13 e versões anteriores) para gerar e comparar representações.

Esta página descreve as ferramentas, o processo de coleta e análise de representações ABI e o uso dessas representações para fornecer estabilidade à ABI no kernel. Esta página também fornece informações para contribuir com mudanças nos kernels do Android.

Processo

A análise da ABI do kernel exige várias etapas, a maioria das quais pode ser automatizada:

As instruções a seguir funcionam para qualquer kernel que possa ser criado usando uma toolchain com suporte (como a toolchain Clang pré-criada). repo manifests estão disponíveis para todos os ramos de kernel comuns do Android e para vários kernels específicos do dispositivo. Elas garantem que a cadeia de ferramentas correta seja usada ao criar uma distribuição de kernel para análise.

Listas de símbolos

O KMI não inclui todos os símbolos do kernel ou mesmo todos os mais de 30.000 símbolos exportados. Em vez disso, os símbolos que podem ser usados por módulos do fornecedor são listados explicitamente em um conjunto de arquivos de lista de símbolos mantidos publicamente na raiz da árvore do kernel. A união de todos os símbolos em todos os arquivos de lista de símbolos define o conjunto de símbolos KMI mantido como estável. Um exemplo de arquivo de lista de símbolos é abi_gki_aarch64_db845c, que declara os símbolos necessários para o DragonBoard 845c.

Somente os símbolos listados em uma lista de símbolos e as estruturas e definições relacionadas são considerados parte do KMI. Você pode postar mudanças nas listas de símbolos se os símbolos necessários não estiverem presentes. Depois que as novas interfaces estiverem em uma lista de símbolos e fizerem parte da descrição do KMI, elas serão mantidas como estáveis e não poderão ser removidas da lista de símbolos nem modificadas depois que a ramificação for congelada.

Cada ramificação do kernel KMI do Kernel comum do Android (ACK, na sigla em inglês) tem seu próprio conjunto de listas de símbolos. Nenhuma tentativa de fornecer estabilidade de ABI entre diferentes ramificações do kernel do KMI. Por exemplo, o KMI para android12-5.10 é completamente independente do KMI para android13-5.10.

As ferramentas da ABI usam listas de símbolos KMI para limitar quais interfaces precisam ser monitoradas quanto à estabilidade. A lista de símbolos principal contém os símbolos necessários pelos módulos do kernel do GKI. Espera-se que os fornecedores enviem e atualizem outras listas de símbolos para garantir que as interfaces em que eles dependem mantenham a compatibilidade com a ABI. Por exemplo, para conferir uma lista de listas de símbolos para android13-5.15, consulte https://android.googlesource.com/kernel/common/+/refs/heads/android13-5.15/android.

Uma lista de símbolos contém os símbolos que são necessários para o fornecedor ou dispositivo específico. A lista completa usada pelas ferramentas é a união de todos os arquivos de lista de símbolos do KMI. As ferramentas ABI determinam os detalhes de cada símbolo, incluindo assinatura da função e estruturas de dados aninhados.

Quando o KMI é congelado, nenhuma mudança é permitida nas interfaces KMI atuais. Elas são estáveis. No entanto, os fornecedores podem adicionar símbolos ao KMI a qualquer momento, desde que as adições não afetem a estabilidade da ABI existente. Os símbolos recém-adicionados são mantidos como estáveis assim que são citados por uma lista de símbolos KMI. Os símbolos não podem ser removidos de uma lista de um kernel, a menos que seja possível confirmar que nenhum dispositivo foi enviado com uma dependência desse símbolo.

É possível gerar uma lista de símbolos de KMI para um dispositivo usando as instruções em Como trabalhar com listas de símbolos. Muitos parceiros enviam uma lista de símbolos por ACK, mas esse não é um requisito fixo. Se isso ajudar na manutenção, você pode enviar várias listas de símbolos.

Estender o KMI

Embora os símbolos do KMI e as estruturas relacionadas sejam mantidos estáveis (ou seja, mudanças que quebram interfaces estáveis em um kernel com um KMI congelado não podem ser aceitas), o kernel do KMI permanece aberto para extensões, para que os dispositivos enviados mais tarde no ano não precisem definir todas as dependências antes que o KMI seja congelado. Para estender o KMI, adicione novos símbolos a ele para funções de kernel exportadas novas ou existentes, mesmo que o KMI esteja congelado. Novos patches do kernel também podem ser aceitos se não interromperem o KMI.

Sobre as quebras de KMI

Um kernel tem origens, e os binários são criados a partir delas. As ramificações do kernel monitoradas pela ABI incluem uma representação da ABI do GKI atual (na forma de um arquivo .stg). Depois que os binários (vmlinux, Image e qualquer módulo GKI) forem criados, uma representação da ABI poderá ser extraída dos binários. Qualquer mudança feita em um arquivo de origem do kernel pode afetar os binários e, por sua vez, também afetar o .stg extraído. O analisador AbiAnalyzer compara o arquivo .stg confirmado com o extraído dos artefatos de build e define um rótulo Lint-1 na mudança no Gerrit se encontrar uma diferença semântica.

Processar interrupções de ABI

Como exemplo, o seguinte patch introduz uma interrupção muito óbvia da ABI:

diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 42786e6364ef..e15f1d0f137b 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -657,6 +657,7 @@ struct mm_struct {
                ANDROID_KABI_RESERVE(1);
        } __randomize_layout;

+       int tickle_count;
        /*
         * The mm_cpumask needs to be at the end of mm_struct, because it
         * is dynamically sized based on nr_cpu_ids.

Quando você executa a ABI de build com esse patch aplicado, a ferramenta é encerrada com um código de erro diferente de zero e informa uma diferença de ABI semelhante a esta:

function symbol 'struct block_device* I_BDEV(struct inode*)' changed
  CRC changed from 0x8d400dbd to 0xabfc92ad

function symbol 'void* PDE_DATA(const struct inode*)' changed
  CRC changed from 0xc3c38b5c to 0x7ad96c0d

function symbol 'void __ClearPageMovable(struct page*)' changed
  CRC changed from 0xf489e5e8 to 0x92bd005e

... 4492 omitted; 4495 symbols have only CRC changes

type 'struct mm_struct' changed
  byte size changed from 992 to 1000
  member 'int tickle_count' was added
  member 'unsigned long cpu_bitmap[0]' changed
    offset changed by 64

Diferenças de ABI detectadas no momento da criação

A causa mais comum de erros é quando um driver usa um novo símbolo do kernel que não está em nenhuma das listas de símbolos.

Se o símbolo não estiver incluído na lista de símbolos (android/abi_gki_aarch64), será necessário verificar primeiro se ele foi exportado com EXPORT_SYMBOL_GPL(symbol_name) e atualizar a lista de símbolos e representação XML da ABI. Por exemplo, as mudanças a seguir adicionam o novo recurso FS incremental à ramificação android-12-5.10, o que inclui a atualização da lista de símbolos e da representação XML da ABI.

O exemplo de mudança de recurso está em aosp/1345659.
O exemplo de lista de símbolos está em aosp/1346742 (link em inglês).
O exemplo de mudança de XML de ABI está em aosp/1349377.

Se o símbolo for exportado (por você ou anteriormente), mas nenhum outro driver o estiver usando, talvez você receba um erro de build semelhante ao seguinte.

Comparing the KMI and the symbol lists:
+ build/abi/compare_to_symbol_list out/$BRANCH/common/Module.symvers out/$BRANCH/common/abi_symbollist.raw
ERROR: Differences between ksymtab and symbol list detected!
Symbols missing from ksymtab:
Symbols missing from symbol list:
 - simple_strtoull

Para resolver, atualize a lista de símbolos KMI no kernel e no ACK (consulte Atualizar a representação da ABI). Para conferir um exemplo de atualização do XML da ABI e da lista de símbolos no ACK, consulte aosp/1367601.

Resolver falhas de ABI do kernel

É possível processar violações de ABI do kernel refactorizando o código para não mudar a ABI ou atualizado a representação da ABI. Use o gráfico a seguir para determinar a melhor abordagem para sua situação.

Fluxograma de interrupção de ABI

Figura 1. Resolução de quebra de ABI

Refatorar o código para evitar mudanças na ABI

Faça o possível para evitar a modificação da ABI existente. Em muitos casos, é possível refactorizar o código para remover mudanças que afetam a ABI.

Refactorização de mudanças de campo de struct. Se uma mudança modificar a ABI para um recurso de depuração, adicione um #ifdef em torno dos campos (nas structs e referências de origem) e verifique se o CONFIG usado para o #ifdef está desativado para o defconfig de produção e o gki_defconfig. Para conferir um exemplo de como uma configuração de depuração pode ser adicionada a uma struct sem interromper a ABI, consulte este patchset.
Refactorizar recursos para não mudar o kernel principal. Se novos recursos precisarem ser adicionados ao ACK para oferecer suporte aos módulos do parceiro, tente refatorar a parte da ABI da mudança para evitar modificar a ABI do kernel. Para conferir um exemplo de como usar a ABI do kernel atual para adicionar outros recursos sem mudar a ABI do kernel, consulte aosp/1312213 (link em inglês).

Corrigir uma ABI corrompida no Android Gerrit

Se você não corromper a ABI do kernel intencionalmente, investigue usando as orientações fornecidas pelas ferramentas de monitoramento de ABI. As causas mais comuns de falhas são alterações nas estruturas de dados e as alterações no CRC do símbolo associado ou devido a alterações na opção de configuração que levam a qualquer uma das opções acima. Comece resolvendo os problemas encontrados pela ferramenta.

Você pode reproduzir os resultados da ABI localmente. Consulte Criar o kernel e a representação da ABI.

Sobre os identificadores do Lint-1

Se você fizer upload de mudanças para uma ramificação que contém uma KMI congelada ou finalizada, elas precisam passar pelo AbiAnalyzer para garantir que não afetem a ABI estável de maneira incompatível. Durante esse processo, o AbiAnalyzer procura o relatório da ABI criado durante o build (um build estendido que executa o build normal e, em seguida, algumas etapas de extração e comparação da ABI.

Se o AbiAnalyzer encontrar um relatório não vazio, ele definirá o rótulo Lint-1 e a mudança será bloqueada para envio até que seja resolvida, até que o conjunto de patches receba um rótulo Lint+1.

Atualizar a ABI do kernel

Se a modificação da ABI for inevitável, será necessário aplicar as mudanças de código, a representação da ABI e a lista de símbolos ao ACK. Para fazer com que o Lint remova o -1 e não quebre a compatibilidade do GKI, siga estas etapas:

Faça upload das alterações de código na ACK.
Aguarde uma resposta de +2 de revisão de código para o conjunto de patches.
Atualize a representação de ABI de referência.
Mescle as mudanças de código e a atualização da ABI.

Faça o upload das mudanças de código ABI para o ACK

A atualização da ABI do ACK depende do tipo de mudança que está sendo feita.

Se uma mudança na ABI estiver relacionada a um recurso que afeta testes CTS ou VTS, a alteração geralmente poderá ser selecionada para o ACK no estado em que se encontra. Por exemplo:
- O aosp/1289677 é necessário para que o áudio funcione.
- aosp/1295945 é necessário para que o USB funcione.
Se uma mudança de ABI for para um recurso que pode ser compartilhado com o ACK, essa mudança poderá ser selecionada para o ACK como está. Por exemplo, as seguintes mudanças não são necessárias para o teste CTS ou VTS, mas podem ser compartilhadas com o ACK:
- aosp/1250412 é uma mudança de recurso térmico.
- aosp/1288857 é uma mudança EXPORT_SYMBOL_GPL.
Se uma mudança na ABI introduzir um novo recurso que não precisa ser incluído no ACK, você pode introduzir os símbolos no ACK usando um stub, conforme descrito na próxima seção.

Usar stubs para ACK

Os stubs precisam ser necessários apenas para mudanças principais do kernel que não beneficiam o ACK, como mudanças de desempenho e energia. A lista a seguir detalha exemplos de stubs e escolhas parciais no ACK para GKI.

Stub do recurso de isolamento do núcleo (aosp/1284493, link em inglês). Os recursos no ACK não são necessários, mas os símbolos precisam estar presentes no ACK para que os módulos os usem.
Símbolo de marcador de posição para o módulo do fornecedor (aosp/1288860).
Seleção de recursos de acompanhamento de eventos mm por processo (aosp/1288454) somente ABI. O patch original foi selecionado a dedo para ACK e, em seguida, cortado para incluir apenas as mudanças necessárias para resolver a diferença de ABI para task_struct e mm_event_count. Esse patch também atualiza o tipo enumerado mm_event_type para conter os membros finais.
Seleção parcial de mudanças na ABI da estrutura térmica que exigiam mais do que apenas adicionar os novos campos da ABI.
- O patch aosp/1255544 resolveu diferenças de ABI entre o kernel do parceiro e o ACK.
- O patch aosp/1291018 corrigiu os problemas funcionais encontrados durante os testes do GKI do patch anterior. A correção incluiu a inicialização da estrutura de parâmetro do sensor para registrar várias zonas térmicas em um único sensor.
Mudanças na ABI CONFIG_NL80211_TESTMODE (aosp/1344321). Esse patch adicionou as mudanças de estrutura necessárias para ABI e garantiu que os campos adicionais não causassem diferenças funcionais, permitindo que os parceiros incluíssem CONFIG_NL80211_TESTMODE nos kernels de produção e ainda mantivessem a conformidade com a GKI.

Aplicar o KMI durante a execução

Os kernels do GKI usam as opções de configuração TRIM_UNUSED_KSYMS=y e UNUSED_KSYMS_WHITELIST=<union of all symbol lists>, que limitam os símbolos exportados (como os símbolos exportados usando EXPORT_SYMBOL_GPL()) aos listados em uma lista de símbolos. Todos os outros símbolos não são exportados, e o carregamento de um módulo que exige um símbolo não exportado é negado. Essa restrição é aplicada no momento da criação e as entradas ausentes são sinalizadas.

Para fins de desenvolvimento, você pode usar um build do kernel de GKI que não inclua o corte de símbolos, o que significa que todos os símbolos geralmente exportados podem ser usados. Para localizar esses builds, procure os builds kernel_debug_aarch64 em ci.android.com.

Aplicar o KMI usando o controle de versões do módulo

Os kernels da imagem genérica do kernel (GKI) usam o controle de versões do módulo (CONFIG_MODVERSIONS) como uma medida adicional para aplicar a conformidade do KMI no tempo de execução. O controle de versão do módulo pode causar falhas de incompatibilidade de verificação cíclica de redundância (CRC) no momento do carregamento do módulo se o KMI esperado de um módulo não corresponder ao KMI vmlinux. Por exemplo, a seguir está uma falha típica que ocorre no tempo de carregamento do módulo devido a uma incompatibilidade de CRC para o símbolo module_layout():

init: Loading module /lib/modules/kernel/.../XXX.ko with args ""
XXX: disagrees about version of symbol module_layout
init: Failed to insmod '/lib/modules/kernel/.../XXX.ko' with args ''

Usos do controle de versões do módulo

O controle de versões do módulo é útil pelos seguintes motivos:

O controle de versões do módulo detecta mudanças na visibilidade da estrutura de dados. Se os módulos mudam estruturas de dados opacas, ou seja, estruturas de dados que não fazem parte do KMI, eles são interrompidos após mudanças futuras na estrutura.

Como exemplo, considere o campo fwnode em struct device. Esse campo PRECISA ser opaco para os módulos, para que eles não possam fazer mudanças nos campos de device->fw_node ou fazer suposições sobre o tamanho.

No entanto, se um módulo incluir <linux/fwnode.h> (diretamente ou indiretamente), o campo fwnode no struct device não será mais opaco para ele. O módulo pode fazer alterações em device->fwnode->dev ou device->fwnode->ops. Esse cenário é problemático por vários motivos, como os seguintes:
- Ele pode quebrar as suposições do código do kernel principal sobre as estruturas de dados internas.
- Se uma futura atualização do kernel mudar o struct fwnode_handle (o tipo de dados de fwnode), o módulo não vai mais funcionar com o novo kernel. Além disso, stgdiff não mostra diferenças porque o módulo está quebrando o KMI ao manipular diretamente estruturas de dados internas de maneiras que não podem ser capturadas apenas inspecionando a representação binária.
Um módulo atual é considerado incompatível com o KMI quando é carregado em uma data posterior por um novo kernel incompatível. O versionamento de módulos adiciona uma verificação de execução para evitar o carregamento acidental de um módulo que não é compatível com o KMI e o kernel. Essa verificação evita problemas de execução difíceis de depurar e falhas do kernel que podem resultar de uma incompatibilidade não detectada no KMI.

Ativar o controle de versões de módulos evita todos esses problemas.

Verifique se há incompatibilidades de CRC sem inicializar o dispositivo

stgdiff compara e informa incompatibilidades de CRC entre kernels e outras diferenças de ABI.

Além disso, um build completo do kernel com CONFIG_MODVERSIONS ativado gera um arquivo Module.symvers como parte do processo de build normal. Esse arquivo tem uma linha para cada símbolo exportado pelo kernel (vmlinux) e pelos módulos. Cada linha consiste no valor do CRC, no nome do símbolo, no namespace do símbolo, no vmlinux ou no nome do módulo que exporta o símbolo e no tipo de exportação (por exemplo, EXPORT_SYMBOL em vez de EXPORT_SYMBOL_GPL).

É possível comparar os arquivos Module.symvers entre o build do GKI e o seu build para verificar se há diferenças de CRC nos símbolos exportados por vmlinux. Se houver uma diferença no valor do CRC em qualquer símbolo exportado por vmlinux e esse símbolo for usado por um dos módulos carregados no dispositivo, o módulo não será carregado.

Se você não tiver todos os artefatos do build, mas tiver os arquivos vmlinux do kernel do GKI e do seu kernel, será possível comparar os valores de CRC de um símbolo específico executando o comando a seguir nos dois kernels e comparando a saída:

nm <path to vmlinux>/vmlinux | grep __crc_<symbol name>

Por exemplo, o comando a seguir verifica o valor CRC do símbolo module_layout:

nm vmlinux | grep __crc_module_layout
0000000008663742 A __crc_module_layout

Resolver incompatibilidades de CRC

Siga estas etapas para resolver uma incompatibilidade de CRC ao carregar um módulo:

Crie o kernel do GKI e do dispositivo usando a opção --kbuild_symtypes, conforme mostrado no comando a seguir:
```
tools/bazel run --kbuild_symtypes //common:kernel_aarch64_dist
```
Esse comando gera um arquivo .symtypes para cada arquivo .o. Consulte KBUILD_SYMTYPES no Kleaf para mais detalhes.

No Android 13 e versões anteriores, crie o kernel de GKI e o kernel do dispositivo adicionando KBUILD_SYMTYPES=1 como prefixo ao comando usado para criar o kernel, conforme mostrado neste comando:
```
KBUILD_SYMTYPES=1 BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
```
Ao usar build_abi.sh,, a flag KBUILD_SYMTYPES=1 já é definida implicitamente.
Encontre o arquivo .c em que o símbolo com incompatibilidade de CRC é exportado usando o seguinte comando:
```
cd common && git grep EXPORT_SYMBOL.*module_layout
kernel/module.c:EXPORT_SYMBOL(module_layout);
```
O arquivo .c tem um arquivo .symtypes correspondente no GKI e nos artefatos de build do kernel do dispositivo. Localize o arquivo .c usando os seguintes comandos:
```
cd out/$BRANCH/common && ls -1 kernel/module.*
kernel/module.o
kernel/module.o.symversions
kernel/module.symtypes
```
Confira a seguir as características do arquivo .c:
- O formato do arquivo .c é uma linha (potencialmente muito longa) por símbolo.
- [s|u|e|etc]# no início da linha significa que o símbolo é do tipo de dados [struct|union|enum|etc]. Exemplo:
```
t#bool typedef _Bool bool
```
- Um prefixo # ausente no início da linha indica que o símbolo é uma função. Exemplo:
```
find_module s#module * find_module ( const char * )
```
Compare os dois arquivos e corrija todas as diferenças.

Caso 1: diferenças devido à visibilidade do tipo de dados

Se um kernel mantém um símbolo ou tipo de dados opaco para os módulos e o outro kernel não, essa diferença aparece entre os arquivos .symtypes dos dois kernels. O arquivo .symtypes de um dos kernels tem UNKNOWN para um símbolo, e o arquivo .symtypes do outro kernel tem uma visualização expandida do símbolo ou do tipo de dados.

Por exemplo, adicionar a linha a seguir ao arquivo include/linux/device.h no kernel causa incompatibilidades de CRC, uma delas é para module_layout():

 #include <linux/fwnode.h>

Comparar o module.symtypes desse símbolo expõe as seguintes diferenças:

 $ diff -u <GKI>/kernel/module.symtypes <your kernel>/kernel/module.symtypes
  --- <GKI>/kernel/module.symtypes
  +++ <your kernel>/kernel/module.symtypes
  @@ -334,12 +334,15 @@
  ...
  -s#fwnode_handle struct fwnode_handle { UNKNOWN }
  +s#fwnode_reference_args struct fwnode_reference_args { s#fwnode_handle * fwnode ; unsigned int nargs ; t#u64 args [ 8 ] ; }
  ...

Se o kernel tiver um valor de UNKNOWN e o kernel do GKI tiver a visualização expandida do símbolo (muito improvável), mescle o kernel comum mais recente do Android ao kernel para usar a base de kernel do GKI mais recente.

Na maioria dos casos, o kernel do GKI tem um valor de UNKNOWN, mas o kernel tem os detalhes internos do símbolo devido a mudanças feitas nele. Isso ocorre porque um dos arquivos no kernel adicionou um #include que não está presente no kernel do GKI.

Muitas vezes, a correção é apenas ocultar o novo #include de genksyms.

#ifndef __GENKSYMS__
#include <linux/fwnode.h>
#endif

Caso contrário, para identificar o #include que causa a diferença, siga estas etapas:

Abra o arquivo de cabeçalho que define o símbolo ou o tipo de dados com essa diferença. Por exemplo, edite include/linux/fwnode.h para o struct fwnode_handle.
Adicione o seguinte código na parte superior do arquivo principal:
```
#ifdef CRC_CATCH
#error "Included from here"
#endif
```
No arquivo .c do módulo que tem uma incompatibilidade de CRC, adicione o seguinte como a primeira linha antes de qualquer uma das linhas #include.
```
#define CRC_CATCH 1
```

Compile o módulo. O erro resultante do tempo de build mostra a cadeia de arquivo de cabeçalho #include que levou a essa incompatibilidade de CRC. Exemplo:

In file included from .../drivers/clk/XXX.c:16:`
In file included from .../include/linux/of_device.h:5:
In file included from .../include/linux/cpu.h:17:
In file included from .../include/linux/node.h:18:
.../include/linux/device.h:16:2: error: "Included from here"
#error "Included from here"

Um dos links nessa cadeia de #include ocorre devido a uma mudança feita no kernel, que está ausente no kernel de GKI.

Identifique a mudança, reverta-a no kernel ou faça upload dela no ACK e faça a mesclagem.

Caso 2: diferenças devido a mudanças no tipo de dados

Se a incompatibilidade de CRC de um símbolo ou tipo de dados não for devido a uma diferença na visibilidade, ela será devido a mudanças reais (adições, remoções ou alterações) no próprio tipo de dados.

Por exemplo, fazer a seguinte mudança no kernel causa várias incompatibilidades de CRC, já que muitos símbolos são afetados indiretamente por esse tipo de mudança:

diff --git a/include/linux/iommu.h b/include/linux/iommu.h
  --- a/include/linux/iommu.h
  +++ b/include/linux/iommu.h
  @@ -259,7 +259,7 @@ struct iommu_ops {
     void (*iotlb_sync)(struct iommu_domain *domain);
     phys_addr_t (*iova_to_phys)(struct iommu_domain *domain, dma_addr_t iova);
     phys_addr_t (*iova_to_phys_hard)(struct iommu_domain *domain,
  -        dma_addr_t iova);
  +        dma_addr_t iova, unsigned long trans_flag);
     int (*add_device)(struct device *dev);
     void (*remove_device)(struct device *dev);
     struct iommu_group *(*device_group)(struct device *dev);

Uma incompatibilidade de CRC é para devm_of_platform_populate().

Se você comparar os arquivos .symtypes desse símbolo, eles vão ficar assim:

 $ diff -u <GKI>/drivers/of/platform.symtypes <your kernel>/drivers/of/platform.symtypes
  --- <GKI>/drivers/of/platform.symtypes
  +++ <your kernel>/drivers/of/platform.symtypes
  @@ -399,7 +399,7 @@
  ...
  -s#iommu_ops struct iommu_ops { ... ; t#phy
  s_addr_t ( * iova_to_phys_hard ) ( s#iommu_domain * , t#dma_addr_t ) ; int
    ( * add_device ) ( s#device * ) ; ...
  +s#iommu_ops struct iommu_ops { ... ; t#phy
  s_addr_t ( * iova_to_phys_hard ) ( s#iommu_domain * , t#dma_addr_t , unsigned long ) ; int ( * add_device ) ( s#device * ) ; ...

Para identificar o tipo alterado, siga estas etapas:

Encontre a definição do símbolo no código-fonte (geralmente em arquivos .h).
- Para diferenças de símbolo entre o kernel e o kernel do GKI, encontre a confirmação executando o seguinte comando:
```
git blame
```
- Para símbolos excluídos (em que um símbolo é excluído em uma árvore e você também quer excluí-lo na outra árvore), é necessário encontrar a mudança que excluiu a linha. Use o seguinte comando na árvore em que a linha foi excluída:
```
git log -S "copy paste of deleted line/word" -- <file where it was deleted>
```
Observação :não copie e cole guias.
Revise a lista de confirmações retornada para localizar a mudança ou exclusão. O primeiro commit é provavelmente o que você está procurando. Se não estiver, analise a lista até encontrar o commit.
Depois de identificar a mudança, reverta-a no kernel ou faça o upload para o ACK e faça a fusão.