A partir de 27 de março de 2025, recomendamos usar android-latest-release em vez de aosp-main para criar e contribuir com o AOSP. Para mais informações, consulte Mudanças no AOSP.

Esta página foi traduzida pela API Cloud Translation.

Monitoramento de ABI do kernel do Android
Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

É possível usar as ferramentas de monitoramento de interface binária de aplicativos (ABI, na sigla em inglês), disponíveis no Android 11 e versões mais recentes, para estabilizar a ABI no kernel de 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 na que a representação oferece uma visualização é chamada de interface de módulo do kernel. (KMI). Você pode usar as ferramentas para acompanhar e mitigar mudanças no KMI.

A ferramenta de monitoramento de ABI é desenvolvida no AOSP e usa o 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 da ABI e o uso dessas representações para dar estabilidade a a 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 você pode criar usando uma conjunto de ferramentas compatível (como o conjunto pré-criado do Clang). 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 pelos módulos do fornecedor são explicitamente listados em um conjunto de arquivos de lista de símbolos mantidos publicamente no diretório raiz. da árvore de kernel. A união de todos os símbolos em todos os arquivos da 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 a 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 no uma lista de símbolos e fazem parte da descrição do KMI, eles são mantidos como estáveis e não deve ser removido da lista de símbolos nem modificado depois que a ramificação congelados.

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 é feita para fornecer estabilidade de ABI entre diferentes ramos do kernel KMI. Por exemplo, o KMI de android12-5.10 é completamente independente o KMI para android13-5.10.

As ferramentas ABI usam listas de símbolos KMI para limitar quais interfaces devem ser monitoradas a estabilidade. A lista de símbolos principal contém os símbolos necessários pelos módulos do kernel do GKI. Os fornecedores são deve enviar e atualizar listas de símbolos adicionais para garantir que o interfaces nas quais dependem mantêm a compatibilidade com 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 relatados como necessários para o determinado fornecedor ou dispositivo. 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 a assinatura da função e estruturas de dados aninhadas.

Quando o KMI está congelado, não são permitidas alterações nas interfaces do KMI existentes. eles sejam 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 atual. Adicionados recentemente símbolos são mantidos tão 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 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 KMI para um dispositivo usando as instruções da Como trabalhar com listas de símbolos. Muitos parceiros enviam uma lista de símbolos por ACK, mas isso não é um requisito obrigatório. Se 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 GKI 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, você pode adicionar novos símbolos a ele para novos funções do kernel exportadas, mesmo que o KMI esteja congelado. Novo kernel também poderão ser aceitos se não violarem o KMI.

Sobre falhas do KMI

Um kernel tem fontes, e os binários são criados a partir dessas fontes. As ramificações de kernel monitoradas pela ABI incluem uma representação da ABI da GKI atual. ABI (na forma de um arquivo .stg). Após os binários (vmlinux, Image e módulos GKI) forem compilados, uma representação de ABI poderá ser extraída do binários. Qualquer alteração feita a um arquivo de origem do kernel pode afetar os binários e por sua vez também afetam 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.

Lidar com falhas de ABI

Por exemplo, o patch a seguir introduz uma falha muito óbvia na 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, as ferramentas saem 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

O motivo mais comum de erros é quando um motorista usa um novo símbolo da kernel que não está em nenhuma das listas de símbolos.

Se o símbolo não estiver na lista (android/abi_gki_aarch64), verifique se ele foi exportado EXPORT_SYMBOL_GPL(symbol_name) e atualizar Representação XML da ABI e lista de símbolos. Por exemplo, as mudanças a seguir adicionam o novo recurso de FS incremental à ramificação android-12-5.10, que inclui a atualização da lista de símbolos e a 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.
O exemplo de mudança de XML ABI está em aosp/1349377.

Se o símbolo for exportado (por você ou anteriormente), mas não outro driver o estiver usando, poderá ocorrer 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 obter um exemplo de atualizar o XML da ABI e a lista de símbolos na 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 seguinte gráfico para determinar a melhor abordagem para sua situação.

Fluxograma de interrupção da ABI

Figura 1. Resolução de quebra de ABI

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

Faça todos os esforços para evitar modificar a ABI atual. Em muitos casos, é possível refatore o código para remover as mudanças que afetam a ABI.

Como refatorar as mudanças no 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 os novos recursos precisarem seja adicionado ao ACK para oferecer suporte aos módulos do parceiro, tente refatorar a ABI parte da mudança para evitar a modificação da ABI do kernel. Para um exemplo de uso a ABI do kernel atual para adicionar recursos sem alterar a a ABI do kernel, consulte aosp/1312213 (link em inglês).

Corrigir uma ABI corrompida no Android Gerrit

Se você não quebrou a ABI do kernel intencionalmente, é necessário investigar, usando as orientações fornecidas pela ferramenta de monitoramento da ABI. As causas mais comuns de falhas são mudanças nas estruturas de dados e nas mudanças de CRC do símbolo associado ou devido a mudanças nas opções de configuração que levam a qualquer uma das mencionadas. Comece resolvendo os problemas encontrados pela ferramenta.

É possível reproduzir as descobertas de ABI localmente. Consulte Crie o kernel e a representação de ABI dele.

Sobre os rótulos do lint-1

Se você fizer o upload de alterações em uma ramificação que contenha um KMI congelado ou finalizado, as mudanças precisam transmitir AbiAnalyzer para garantir que elas não afetem a propriedade estável. ABI de maneira incompatível. Durante esse processo, o AbiAnalyzer procura o relatório ABI criado durante o build, um build estendido que executa o build normal e depois algumas etapas de extração e comparação de ABI.

Se o AbiAnalyzer encontrar um relatório não vazio, ele definirá o rótulo do Lint-1 e a o envio de mudanças está bloqueado até ser resolvido; até que o patchset receba uma 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 que o lint remover o -1 e não interromper a compatibilidade de GKI, siga estas etapas:

Envie as mudanças de código para o ACK.
Aguarde até receber uma revisão de código +2 para o patchset.
Atualizar a representação de ABI de referência.
Combine as mudanças de código e a mudança de atualização da ABI.

Fazer upload de alterações do código ABI para o código 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 pode ser escolhida a dedo para o ACK no estado em que se encontra. Por exemplo:
- (AOSP/1289677). para que o áudio funcione.
- O 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 introduz um novo recurso que não precisa ser incluído no é possível introduzir a ACK usando um stub, conforme descrito seção a seguir.

Usar stubs para ACK

Os stubs precisam ser necessários somente para alterações do kernel que não beneficiam o ACK, como mudanças de desempenho e energia. Os exemplos de detalhes da lista a seguir de stubs e seleções parciais em ACK para GKI.

Estubor de recurso de isolamento do núcleo (aosp/1284493). Os recursos de ACK não são necessários, mas os símbolos precisam estar presentes em ACK para que os módulos usem esses símbolos.
Símbolo de marcador de posição para o módulo do fornecedor (aosp/1288860).
Escolha a seguir somente para ABI do recurso de acompanhamento de eventos mm por processo (osp/1288454). O patch original foi escolhido para ACK e depois reduzido para incluir apenas as mudanças necessárias para resolver a diferença de ABI de task_struct e mm_event_count. Esse patch também atualiza o tipo enumerado mm_event_type para conter os membros finais.
Escolha parcial de mudanças de ABI de estrutura térmica que exigiam mais do que apenas adicionar os novos campos de ABI.
- Adesivo (osp/1255544). foram resolvidas as diferenças de ABI entre o kernel do parceiro e a 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 alterações necessárias ao struct para a ABI e garantiu que o campos adicionais não causaram diferenças funcionais, permitindo que os parceiros para incluir CONFIG_NL80211_TESTMODE nos kernels de produção e ainda manter a conformidade com a GKI.

Aplicar o KMI no momento da 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 corte de símbolo (ou seja, todos os símbolos geralmente exportados podem ser usados). Para localizar esses builds, procure os builds kernel_debug_aarch64 em ci.android.com (link em inglês).

Aplicar o KMI usando o controle de versões de módulos

Os kernels de imagem genérica do kernel (GKI, na sigla em inglês) usam o controle de versões de módulos (CONFIG_MODVERSIONS) como medida adicional para garantir a conformidade com o KMI em no ambiente 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 falha a seguir é uma falha típica que ocorre 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ão de módulo

O controle de versão de módulos é útil pelos seguintes motivos:

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

Por exemplo, considere o fwnode no 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 pode fazer mudanças 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 que o código do kernel principal está fazendo sobre as estruturas de dados internas.
- Se uma futura atualização do kernel mudar o struct fwnode_handle (os dados tipo de fwnode), o módulo não funcionará mais 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 tempo de execução para evitar o carregamento acidental de um módulo que não seja compatível com o KMI no kernel. Essa verificação evita problemas de execução difíceis de depurar e falhas do kernel que podem resultantes 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. Este arquivo tem um 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).

Você pode comparar os arquivos Module.symvers entre o build GKI e seu build para verificar diferenças de CRC nos símbolos exportados pelo 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 do CRC para o objeto module_layout. símbolo:

nm vmlinux | grep __crc_module_layout
0000000008663742 A __crc_module_layout

Resolver incompatibilidades de CRC

Use as etapas a seguir 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.

Para o Android 13 e versões anteriores, crie o kernel do GKI e do dispositivo precedido por KBUILD_SYMTYPES=1 no comando usado para criar o kernel, conforme mostrado no comando a seguir:
```
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 na GKI, e seu 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 não, essa diferença aparece entre os arquivos .symtypes dos dois kernels. O arquivo .symtypes de um dos kernels tem UNKNOWN de um símbolo, e o arquivo .symtypes do outro kernel tiver uma visualização expandida do símbolo ou 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>

A comparação do module.symtypes para esse 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 UNKNOWN e o kernel de GKI tiver a visualização expandida do símbolo (muito improvável), depois mesclar o kernel comum mais recente do Android nos seu kernel para que você esteja usando a base de kernel de 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 principal que define o símbolo ou tipo de dados que tem este diferença. Por exemplo, edite include/linux/fwnode.h para o struct fwnode_handle.
Adicione o seguinte código na parte de cima do arquivo de cabeçalho:
```
#ifdef CRC_CATCH
#error "Included from here"
#endif
```
No arquivo .c do módulo que tem uma incompatibilidade de CRC, adicione o seguindo como a primeira linha antes de qualquer uma das linhas #include.
```
#define CRC_CATCH 1
```

Compile seu módulo. O erro de tempo de build resultante mostra a cadeia de arquivo principal #include que causou 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 nesta cadeia de #include se deve a uma alteração nas suas que está faltando 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 alteração 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, ele poderá 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ído:
```
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 retornada de commits para localizar a mudança ou exclusão. O primeiro commit é provavelmente o que você está procurando. Caso contrário, navegue pela lista até encontrar a confirmação.
Depois de identificar a mudança, reverta-a no kernel ou fazer o upload no ACK e obtê-lo mesclado.