Desenvolvimento Kernel Mainline - Patches - Fixes

#1

Olá,

há algum git repo “-next” com trabalho para suportar o Kernel Mainline?
Gostaria de contribuir para o driver de pinctrl, mas talvez eu venha a fazer “retrabalho” caso já tenha avanços.

Abraços,
Matheus Castello

#2

Olá @matheus , por hora não há um esforço para suportar Mainline, mas é algo a ser feito no futuro.

Bem quanto ao driver de pinctrl, na versão 32 bits, realmente é algo a ser feito, não tivemos avanço neste driver já faz algum tempo, pode trabalhar nele, não há outras pessoas trabalhando com ele.

Obrigado pela iniciativa!

Att,

Igor Ruschi

#3

Olá @ruschigo ,

ok então, vou trabalhando aqui e reporto os avanços no forum.

Obrigado, abraços!

1 Like
#4

Update: tenho uma versão do Kernel 5.5-rc7 rodando.

:white_check_mark: clocks (actions,s500-cmu)
:white_check_mark: pinctrl (actions,s500-pinctrl “baseado no actions,s700-pinctrl”)
:white_check_mark: uart (actions,s500-uart)

Estou configurando a uart3 já com o pinctrl e o clock do mainline, e ela responde com os logs de printk:

:x: Preciso agora acertar os nós de mcc para ter algo mais útil, ir para user space em rootfs. Adicionar alguns detalhes de clock reset, para verificar se o owl-mmc (actions,owl-mmc) vai ser compatível. (Me parece favorável em uma primeira analise)

#5

Vou começar a colocar aqui também os patches enviados para upstream:

pinctrl: actions: Fix functions groups names

drivers/pinctrl/actions/pinctrl-s700.c
https://patchwork.kernel.org/patch/11350329/

1 Like
#6

clocksource: owl: Improve owl_timer_init fail messages

drivers/clocksource/timer-owl.c

https://patchwork.kernel.org/patch/11381779/

#7

Resolvendo alguns problemas, no meu defconfig, que estavam causando “RCU stalls”, agora eu tenho um initramfs com Busybox para me ajudar nos testes com mainline:

1 Like
#8

Muito bom!!

Acredito que em breve(próximo mês), vou liberar uma versão do Kernel 5.3, ao menos para a labrador arm32, aproveito para avaliar e adicionar a sua contribuição do pinctrl, é nesse repositório que você mantém ele?

Att,

Igor Ruschi

#9

Olá @ruschigo,

estou mantendo meus testes aqui na verdade: https://github.com/microhobby/linus-tree/

Você pode notar que os commits estão com “WIP”, eu não acho que eles estão bons ainda para irem para produção, ou para enviar para mainline por exemplo.

Eu esperaria até que fosse incluído no mainline para usar. Por exemplo: https://patchwork.kernel.org/patch/11350329/ já foi aceito pelos mantenedores, deve entrar até a próxima release candidate do 5.6

Abraços

#10

Obrigado Matheus,

Bem ainda vou demorar um pouco para prosseguir com isso, mas quero em futuro próximo fazer um driver de clock novo para labrador 32bits, quando for fazer isso olho como está o status do seu pincrtl, daí qualquer coisa posto aqui novamente.

Att,

Igor Ruschi

1 Like
#11

Add Caninos Loucos Labrador SoM and Base Board Device Tree

dt-bindings: arm: actions: Document Caninos Loucos Labrador

Documentation/devicetree/bindings/arm/actions.yaml
Documentation/devicetree/bindings/vendor-prefixes.yaml

https://patchwork.kernel.org/patch/11409607/

ARM: dts: Add Caninos Loucos Labrador

arch/arm/boot/dts/Makefile
arch/arm/boot/dts/owl-s500-labrador-bb.dts
arch/arm/boot/dts/owl-s500-labrador-v2.dtsi

https://patchwork.kernel.org/patch/11409609/

v2

https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=252745

#12

Olá @augusto e @ruschigo,

estou adicionando a Caninos Loucos como fabricante de dispositivos no mainline e preciso da ajuda de vocês para um input sobre a pergunta do mantenedor do Actions Semi. Deem uma olhada aqui se possível: https://patchwork.kernel.org/patch/11424883/

Gostaria de colocar alguém do time da Caninos como CC nos patches também, como o mantenedor achou melhor, para continuarmos com as decisões.

Em suma a dúvida é sobre o vendor prefix. Utilizar caninos,labrador por exemplo, a Caninos é independente o bastante para ter sua própria vendor-prefix, ou deveríamos ter o vendor-prefix da LSI-TEC lsi-tec,caninosloucos-labrador?

Desde já agradeço,
Abraços!

#13

@matheus, Boa Tarde!

O que temos utilizado internamente é o prefixo ‘caninos,kx-driver-name’, devido a termos duas arquiteturas arm32 e arm64, chamamos a 32 bits de k5 e a 64 bits de k7, então por exemplo, para um driver de uart para a 32 bits, seria ‘caninos,k5-uart’. Assim podemos ter maior flexibilidade no futuro para outros desenvolvimentos para caninos.

Inicialmente quando havia apenas a 32 bits as core V2.x, era usado o prefixo ‘caninos,labrador-drivername’, mas com o desenvolvimento da 64 bits, terminamos criando uma nova terminologia ‘kx’.

Então genericamente, podemos utilizar assim;

caninos,device-driver-name

o ‘device’, atualmente temos os k5 e k7.

Coloque o @edgar.righi em cópia, edgar.righi@lsitec.org.br, se quiser pode me adicionar também igor.lima@lsitec.org.br

Att,

Igor Ruschi

1 Like
#14

Obrigado @ruschigo, adicionados!

#15

Add Caninos Loucos Labrador SoM and Base Board Device Tree

Nova versão da serie: https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=259135

@ruschigo e @edgar.righi gostaria que vocês, se possivel, enviassem um “Acked-by:” para o seguinte commit https://patchwork.kernel.org/patch/11448393/ para mostrar acordo com o que foi conversado de usar o prefixo “caninos,*” ao invés de “lsi-tec,*”

Se não tiverem de acordo deixe-me saber.
Abraços!