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 de ABI são os arquivos .stg e as listas de símbolos. A interface em que a representação mostra uma visualização é chamada de Interface de módulo do kernel (KMI, na sigla em inglês). 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 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 no 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 de KMI mantidos como estáveis. 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 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 é feita para fornecer estabilidade de ABI entre diferentes ramos do kernel KMI. Por exemplo, o KMI para android12-5.10 é completamente independente do KMI para android13-5.10.

As ferramentas ABI usam listas de símbolos KMI para limitar quais interfaces precisam ser monitoradas para 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 a assinatura da função e estruturas de dados aninhadas.

Quando o KMI está congelado, nenhuma mudança é permitida nas interfaces KMI existentes. 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 atual. 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 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 do 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.

Lidar com falhas 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), você precisará verificar primeiro se ele foi exportado com EXPORT_SYMBOL_GPL(symbol_name) e depois atualizar a representação XML da ABI e a 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 (link em inglês).
O exemplo de lista de símbolos está em aosp/1346742.
O exemplo de mudança de XML de ABI está em aosp/1349377.

Se o símbolo for exportado (por você ou se ele foi exportado anteriormente), mas nenhum outro driver estiver usando, você poderá receber 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 falhas de ABI do kernel refatorando o código para não mudar a ABI ou atualizando 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 todos os esforços para evitar modificar a ABI atual. Em muitos casos, é possível refactorizar o código para remover mudanças que afetam a ABI.

Como refatorar as mudanças no campo de struct. Se uma mudança modificar a ABI de um recurso de depuração, adicione um #ifdef ao redor dos campos (nas referências de estruturas e fonte) 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 à ACK para oferecer suporte aos módulos do parceiro, tente refatorar a parte da ABI da mudança para evitar a modificação da 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 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 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 rótulos 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 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 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 o upload das mudanças de código para o 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.
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 de ABI estiver relacionada a um recurso que afeta os testes CTS ou VTS, ela pode ser selecionada para ACK como está. 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 de ACK não são necessários, mas os símbolos precisam estar presentes na ACK para que os módulos usem esses símbolos.
Símbolo de marcador de posição do módulo do fornecedor (aosp/1288860, link em inglês).
Seleção de recursos de acompanhamento de eventos mm por processo (aosp/1288454) somente ABI. 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 para task_struct e mm_event_count. Esse patch também atualiza o tipo enumerado mm_event_type para conter os membros finais.
Parte das mudanças da 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 do struct do 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 no momento da execução

Os kernels de 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 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ão de módulos é ú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 supor 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 mudanças em device->fwnode->dev ou device->fwnode->ops. Esse cenário é problemático por vários motivos, indicados a seguir:
- Ele pode quebrar as suposições que o código do kernel principal está fazendo sobre as estruturas de dados internas.
- Se uma atualização futura 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 tem todos os artefatos de build, mas tem os arquivos vmlinux do kernel de GKI e do kernel, é possível comparar os valores de CRC para um símbolo específico executando o comando abaixo 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.

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 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 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 seguinte linha ao arquivo include/linux/device.h no kernel causa incompatibilidades de CRC, uma delas para module_layout():

 #include <linux/fwnode.h>

Comparar a 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 de 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 o tipo de dados que tem essa 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 seguinte como a primeira linha antes de qualquer uma das linhas #include.
```
#define CRC_CATCH 1
```

Compile o módulo. O erro de tempo de build resultante mostra a cadeia do 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 para um símbolo ou tipo de dados não for devido a uma diferença na visibilidade, é devido a alterações 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, 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 comando a seguir 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 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 faça o upload para o ACK e faça a fusão.