* Re: [PATCH 0/3] arm64: dts: rockchip: add support for iesy RPX30 SoM OSM-S
From: Rob Herring @ 2024-03-20 16:20 UTC (permalink / raw)
To: Dominik Poggel
Cc: linux-kernel, linux-rockchip, Andy Yan, Chris Morgan,
Ondrej Jirman, Conor Dooley, devicetree, robh+dt,
linux-arm-kernel, Tianling Shen, Krzysztof Kozlowski,
Heiko Stuebner
In-Reply-To: <20240319095411.4112296-1-pog@iesy.com>
On Tue, 19 Mar 2024 10:53:59 +0100, Dominik Poggel wrote:
> Add dts files for SoM and baseboard featuring rockchip PX30 SoC
>
> Add iesy GmbH to dt-bindings: vendor-prefixes
>
> Add baseboard to dt-bindings: arm: rockchip
>
> Dominik Poggel (3):
> arm64: dts: iesy: add support for iesy PX30 SoM OSM-S
> dt-bindings: vendor-prefixes: add iesy
> dt-bindings: arm: rockchip: add iesy RPX30 evaluation board
>
> .../devicetree/bindings/arm/rockchip.yaml | 5 +
> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> arch/arm64/boot/dts/rockchip/Makefile | 1 +
> .../boot/dts/rockchip/px30-iesy-eva-mi-v2.dts | 682 ++++++++++++++++++
> .../boot/dts/rockchip/px30-iesy-osm-sf.dtsi | 362 ++++++++++
> 5 files changed, 1052 insertions(+)
> create mode 100644 arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dts
> create mode 100644 arch/arm64/boot/dts/rockchip/px30-iesy-osm-sf.dtsi
>
> --
> 2.44.0
>
>
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
New warnings running 'make CHECK_DTBS=y rockchip/px30-iesy-eva-mi-v2.dtb' for 20240319095411.4112296-1-pog@iesy.com:
arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dtb: /: regulator@1: 'anyOf' conditional failed, one must be fixed:
'reg' is a required property
'ranges' is a required property
from schema $id: http://devicetree.org/schemas/root-node.yaml#
arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dtb: /: regulator@2: 'anyOf' conditional failed, one must be fixed:
'reg' is a required property
'ranges' is a required property
from schema $id: http://devicetree.org/schemas/root-node.yaml#
arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dtb: /: regulator@4: 'anyOf' conditional failed, one must be fixed:
'reg' is a required property
'ranges' is a required property
from schema $id: http://devicetree.org/schemas/root-node.yaml#
arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dtb: opp-table-0: Unevaluated properties are not allowed ('rockchip,avs' was unexpected)
from schema $id: http://devicetree.org/schemas/opp/opp-v2.yaml#
arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dtb: power-controller: 'pd_gpu-supply', 'pd_mmc_nand-supply', 'pd_usb-supply', 'pd_vi-supply', 'pd_vo-supply', 'pd_vpu-supply' do not match any of the regexes: '^power-domain@[0-9a-f]+$', 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/power/rockchip,power-controller.yaml#
arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dtb: syscon@ff140000: io-domains: Unevaluated properties are not allowed ('pmuio1-supply', 'pmuio2-supply' were unexpected)
from schema $id: http://devicetree.org/schemas/soc/rockchip/grf.yaml#
arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dtb: syscon@ff140000: io-domains: Unevaluated properties are not allowed ('pmuio1-supply', 'pmuio2-supply' were unexpected)
from schema $id: http://devicetree.org/schemas/soc/rockchip/grf.yaml#
arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dtb: io-domains: Unevaluated properties are not allowed ('pmuio1-supply', 'pmuio2-supply' were unexpected)
from schema $id: http://devicetree.org/schemas/power/rockchip-io-domain.yaml#
arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dtb: pmic@20: 'pinctrl_rk8xx', 'pmic-reset-func', 'pwrkey' do not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/mfd/rockchip,rk809.yaml#
arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dtb: /i2c@ff180000/rtc@68: failed to match any schema with compatible: ['adi,max31343']
arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dtb: /i2c@ff180000/sensor@4e: failed to match any schema with compatible: ['lm75']
arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dtb: /i2c@ff190000/lt8912@48: failed to match any schema with compatible: ['lontium,lt8912']
arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dtb: audio_codec@18: 'clocks' is a required property
from schema $id: http://devicetree.org/schemas/sound/maxim,max9867.yaml#
arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dtb: audio_codec@18: 'anyOf' conditional failed, one must be fixed:
'clocks' is a required property
'#clock-cells' is a required property
from schema $id: http://devicetree.org/schemas/clock/clock.yaml#
arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dtb: /spi@ff1d0000/spidev@0: failed to match any schema with compatible: ['memsic,mc3630']
arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dtb: spidev@0: $nodename:0: 'spidev@0' does not match '^(flash|.*sram|nand)(@.*)?$'
from schema $id: http://devicetree.org/schemas/mtd/jedec,spi-nor.yaml#
arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dtb: syscon@ff2c0000: usb2phy@100:host-port: 'vbus-supply' does not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/soc/rockchip/grf.yaml#
arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dtb: syscon@ff2c0000: usb2phy@100:otg-port: 'vbus-supply' does not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/soc/rockchip/grf.yaml#
arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dtb: usb2phy@100: host-port: 'vbus-supply' does not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/phy/rockchip,inno-usb2phy.yaml#
arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dtb: usb2phy@100: otg-port: 'vbus-supply' does not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/phy/rockchip,inno-usb2phy.yaml#
arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dtb: ethernet@ff360000: Unevaluated properties are not allowed ('gmac0_mdio' was unexpected)
from schema $id: http://devicetree.org/schemas/net/rockchip-dwmac.yaml#
arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dtb: ethernet-phy@0: 'vsc8531,edge-slowdown', 'vsc8531,led-0-mode', 'vsc8531,led-1-mode', 'vsc8531,vddmac' do not match any of the regexes: '^#.*', '^(at25|bm|devbus|dmacap|dsa|exynos|fsi[ab]|gpio-fan|gpio-key|gpio|gpmc|hdmi|i2c-gpio),.*', '^(keypad|m25p|max8952|max8997|max8998|mpmc),.*', '^(pinctrl-single|#pinctrl-single|PowerPC),.*', '^(pl022|pxa-mmc|rcar_sound|rotary-encoder|s5m8767|sdhci),.*', '^(simple-audio-card|st-plgpio|st-spics|ts),.*', '^100ask,.*', '^70mai,.*', '^8dev,.*', '^GEFanuc,.*', '^IBM,.*', '^ORCL,.*', '^SUNW,.*', '^[a-zA-Z0-9#_][a-zA-Z0-9+\-._@]{0,63}$', '^[a-zA-Z0-9+\-._]*@[0-9a-zA-Z,]*$', '^abb,.*', '^abilis,.*', '^abracon,.*', '^abt,.*', '^acbel,.*', '^acelink,.*', '^acer,.*', '^acme,.*', '^actions,.*', '^active-semi,.*', '^ad,.*', '^adafruit,.*', '^adapteva,.*', '^adaptrum,.*', '^adh,.*', '^adi,.*', '^adieng,.*', '^admatec,.*', '^advantech,.*', '^aeroflexgaisler,.*', '^aesop,.*', '^airoha,.*', '^al,.*', '^alcate
l,.*', '^aldec,.*', '^alfa-network,.*', '^allegro,.*', '^alliedvision,.*', '^allo,.*', '^allwinner,.*', '^alphascale,.*', '^alps,.*', '^alt,.*', '^altr,.*', '^amarula,.*', '^amazon,.*', '^amcc,.*', '^amd,.*', '^amediatech,.*', '^amlogic,.*', '^ampere,.*', '^amphenol,.*', '^ampire,.*', '^ams,.*', '^amstaos,.*', '^analogix,.*', '^anbernic,.*', '^andestech,.*', '^anvo,.*', '^aosong,.*', '^apm,.*', '^apple,.*', '^aptina,.*', '^arasan,.*', '^archermind,.*', '^arcom,.*', '^arctic,.*', '^arcx,.*', '^aries,.*', '^arm,.*', '^armadeus,.*', '^arrow,.*', '^artesyn,.*', '^asahi-kasei,.*', '^asc,.*', '^asix,.*', '^aspeed,.*', '^asrock,.*', '^asteralabs,.*', '^asus,.*', '^atheros,.*', '^atlas,.*', '^atmel,.*', '^auo,.*', '^auvidea,.*', '^avago,.*', '^avia,.*', '^avic,.*', '^avnet,.*', '^awinic,.*', '^axentia,.*', '^axis,.*', '^azoteq,.*', '^azw,.*', '^baikal,.*', '^bananapi,.*', '^beacon,.*', '^beagle,.*', '^belling,.*', '^bhf,.*', '^bigtreetech,.*', '^bitmain,.*', '^blutek,.*', '^boe,.*', '^bosch
,.*', '^boundary,.*', '^brcm,.*', '^broadmobi,.*', '^bsh,.*', '^bticino,.*', '^buffalo,.*', '^bur,.*', '^bytedance,.*', '^calamp,.*', '^calao,.*', '^calaosystems,.*', '^calxeda,.*', '^canaan,.*', '^caninos,.*', '^capella,.*', '^cascoda,.*', '^catalyst,.*', '^cavium,.*', '^cdns,.*', '^cdtech,.*', '^cellwise,.*', '^ceva,.*', '^chargebyte,.*', '^checkpoint,.*', '^chefree,.*', '^chipidea,.*', '^chipone,.*', '^chipspark,.*', '^chongzhou,.*', '^chrontel,.*', '^chrp,.*', '^chunghwa,.*', '^chuwi,.*', '^ciaa,.*', '^cirrus,.*', '^cisco,.*', '^clockwork,.*', '^cloos,.*', '^cloudengines,.*', '^cnm,.*', '^cnxt,.*', '^colorfly,.*', '^compulab,.*', '^congatec,.*', '^coolpi,.*', '^coreriver,.*', '^corpro,.*', '^cortina,.*', '^cosmic,.*', '^crane,.*', '^creative,.*', '^crystalfontz,.*', '^csky,.*', '^csq,.*', '^ctera,.*', '^ctu,.*', '^cubietech,.*', '^cui,.*', '^cypress,.*', '^cyx,.*', '^cznic,.*', '^dallas,.*', '^dataimage,.*', '^davicom,.*', '^dell,.*', '^delta,.*', '^densitron,.*', '^denx,.*', '^
devantech,.*', '^dfi,.*', '^dh,.*', '^difrnce,.*', '^digi,.*', '^digilent,.*', '^dimonoff,.*', '^diodes,.*', '^dioo,.*', '^dlc,.*', '^dlg,.*', '^dlink,.*', '^dmo,.*', '^domintech,.*', '^dongwoon,.*', '^dptechnics,.*', '^dragino,.*', '^ds,.*', '^dserve,.*', '^dynaimage,.*', '^ea,.*', '^ebang,.*', '^ebbg,.*', '^ebs-systart,.*', '^ebv,.*', '^eckelmann,.*', '^edgeble,.*', '^edimax,.*', '^edt,.*', '^ees,.*', '^eeti,.*', '^einfochips,.*', '^eink,.*', '^elan,.*', '^element14,.*', '^elgin,.*', '^elida,.*', '^elimo,.*', '^elpida,.*', '^embedfire,.*', '^embest,.*', '^emlid,.*', '^emmicro,.*', '^empire-electronix,.*', '^emtrion,.*', '^enclustra,.*', '^endless,.*', '^ene,.*', '^energymicro,.*', '^engicam,.*', '^engleder,.*', '^epcos,.*', '^epfl,.*', '^epson,.*', '^esp,.*', '^est,.*', '^ettus,.*', '^eukrea,.*', '^everest,.*', '^everspin,.*', '^evervision,.*', '^exar,.*', '^excito,.*', '^exegin,.*', '^ezchip,.*', '^facebook,.*', '^fairchild,.*', '^fairphone,.*', '^faraday,.*', '^fascontek,.*', '^
fastrax,.*', '^fcs,.*', '^feixin,.*', '^feiyang,.*', '^fii,.*', '^firefly,.*', '^focaltech,.*', '^forlinx,.*', '^freebox,.*', '^freecom,.*', '^frida,.*', '^friendlyarm,.*', '^fsl,.*', '^fujitsu,.*', '^fxtec,.*', '^galaxycore,.*', '^gardena,.*', '^gateway,.*', '^gateworks,.*', '^gcw,.*', '^ge,.*', '^geekbuying,.*', '^gef,.*', '^gemei,.*', '^gemtek,.*', '^genesys,.*', '^geniatech,.*', '^giantec,.*', '^giantplus,.*', '^glinet,.*', '^globalscale,.*', '^globaltop,.*', '^gmt,.*', '^goldelico,.*', '^goodix,.*', '^google,.*', '^goramo,.*', '^gplus,.*', '^grinn,.*', '^grmn,.*', '^gumstix,.*', '^gw,.*', '^hannstar,.*', '^haochuangyi,.*', '^haoyu,.*', '^hardkernel,.*', '^hechuang,.*', '^hideep,.*', '^himax,.*', '^hirschmann,.*', '^hisi,.*', '^hisilicon,.*', '^hit,.*', '^hitex,.*', '^holt,.*', '^holtek,.*', '^honestar,.*', '^honeywell,.*', '^hoperf,.*', '^hoperun,.*', '^hp,.*', '^hpe,.*', '^hsg,.*', '^htc,.*', '^huawei,.*', '^hugsun,.*', '^hwacom,.*', '^hxt,.*', '^hycon,.*', '^hydis,.*', '^hyni
tron,.*', '^hynix,.*', '^hyundai,.*', '^i2se,.*', '^ibm,.*', '^icplus,.*', '^idt,.*', '^iei,.*', '^iesy,.*', '^ifi,.*', '^ilitek,.*', '^imagis,.*', '^img,.*', '^imi,.*', '^inanbo,.*', '^incircuit,.*', '^indiedroid,.*', '^inet-tek,.*', '^infineon,.*', '^inforce,.*', '^ingenic,.*', '^ingrasys,.*', '^injoinic,.*', '^innocomm,.*', '^innolux,.*', '^inside-secure,.*', '^insignal,.*', '^inspur,.*', '^intel,.*', '^intercontrol,.*', '^invensense,.*', '^inventec,.*', '^inversepath,.*', '^iom,.*', '^irondevice,.*', '^isee,.*', '^isil,.*', '^issi,.*', '^ite,.*', '^itead,.*', '^itian,.*', '^ivo,.*', '^iwave,.*', '^jadard,.*', '^jasonic,.*', '^jdi,.*', '^jedec,.*', '^jesurun,.*', '^jethome,.*', '^jianda,.*', '^jide,.*', '^joz,.*', '^kam,.*', '^karo,.*', '^keithkoep,.*', '^keymile,.*', '^khadas,.*', '^kiebackpeter,.*', '^kinetic,.*', '^kingdisplay,.*', '^kingnovel,.*', '^kionix,.*', '^kobo,.*', '^kobol,.*', '^koe,.*', '^kontron,.*', '^kosagi,.*', '^kvg,.*', '^kyo,.*', '^lacie,.*', '^laird,.*', '^l
amobo,.*', '^lantiq,.*', '^lattice,.*', '^lctech,.*', '^leadtek,.*', '^leez,.*', '^lego,.*', '^lemaker,.*', '^lenovo,.*', '^lg,.*', '^lgphilips,.*', '^libretech,.*', '^licheepi,.*', '^linaro,.*', '^lineartechnology,.*', '^linksprite,.*', '^linksys,.*', '^linutronix,.*', '^linux,.*', '^linx,.*', '^liteon,.*', '^litex,.*', '^lltc,.*', '^logicpd,.*', '^logictechno,.*', '^longcheer,.*', '^lontium,.*', '^loongmasses,.*', '^loongson,.*', '^lsi,.*', '^lunzn,.*', '^luxul,.*', '^lwn,.*', '^lxa,.*', '^m5stack,.*', '^macnica,.*', '^mantix,.*', '^mapleboard,.*', '^marantec,.*', '^marvell,.*', '^maxbotix,.*', '^maxim,.*', '^maxlinear,.*', '^mbvl,.*', '^mcube,.*', '^meas,.*', '^mecer,.*', '^mediatek,.*', '^megachips,.*', '^mele,.*', '^melexis,.*', '^melfas,.*', '^mellanox,.*', '^memsensing,.*', '^memsic,.*', '^menlo,.*', '^mentor,.*', '^meraki,.*', '^merrii,.*', '^methode,.*', '^micrel,.*', '^microchip,.*', '^microcrystal,.*', '^micron,.*', '^microsoft,.*', '^microsys,.*', '^mikroe,.*', '^mikroti
k,.*', '^milkv,.*', '^miniand,.*', '^minix,.*', '^mips,.*', '^miramems,.*', '^mitsubishi,.*', '^mitsumi,.*', '^mixel,.*', '^miyoo,.*', '^mntre,.*', '^mobileye,.*', '^modtronix,.*', '^moortec,.*', '^mosaixtech,.*', '^motorcomm,.*', '^motorola,.*', '^moxa,.*', '^mpl,.*', '^mps,.*', '^mqmaker,.*', '^mrvl,.*', '^mscc,.*', '^msi,.*', '^mstar,.*', '^mti,.*', '^multi-inno,.*', '^mundoreader,.*', '^murata,.*', '^mxic,.*', '^mxicy,.*', '^myir,.*', '^national,.*', '^nec,.*', '^neonode,.*', '^netgear,.*', '^netlogic,.*', '^netron-dy,.*', '^netronix,.*', '^netxeon,.*', '^neweast,.*', '^newhaven,.*', '^newvision,.*', '^nexbox,.*', '^nextthing,.*', '^ni,.*', '^nintendo,.*', '^nlt,.*', '^nokia,.*', '^nordic,.*', '^novatek,.*', '^novtech,.*', '^numonyx,.*', '^nutsboard,.*', '^nuvoton,.*', '^nvd,.*', '^nvidia,.*', '^nxp,.*', '^oceanic,.*', '^ocs,.*', '^oct,.*', '^okaya,.*', '^oki,.*', '^olimex,.*', '^olpc,.*', '^oneplus,.*', '^onie,.*', '^onion,.*', '^onnn,.*', '^ontat,.*', '^opalkelly,.*', '^openai
lab,.*', '^opencores,.*', '^openembed,.*', '^openpandora,.*', '^openrisc,.*', '^option,.*', '^oranth,.*', '^orisetech,.*', '^ortustech,.*', '^osddisplays,.*', '^osmc,.*', '^ouya,.*', '^overkiz,.*', '^ovti,.*', '^oxsemi,.*', '^ozzmaker,.*', '^panasonic,.*', '^parade,.*', '^parallax,.*', '^pda,.*', '^pericom,.*', '^pervasive,.*', '^phicomm,.*', '^phytec,.*', '^picochip,.*', '^pine64,.*', '^pineriver,.*', '^pixcir,.*', '^plantower,.*', '^plathome,.*', '^plda,.*', '^plx,.*', '^ply,.*', '^pni,.*', '^pocketbook,.*', '^polaroid,.*', '^polyhex,.*', '^portwell,.*', '^poslab,.*', '^pov,.*', '^powertip,.*', '^powervr,.*', '^powkiddy,.*', '^primux,.*', '^probox2,.*', '^prt,.*', '^pulsedlight,.*', '^purism,.*', '^qca,.*', '^qcom,.*', '^qemu,.*', '^qi,.*', '^qiaodian,.*', '^qihua,.*', '^qishenglong,.*', '^qnap,.*', '^quanta,.*', '^radxa,.*', '^raidsonic,.*', '^ralink,.*', '^ramtron,.*', '^raspberrypi,.*', '^raydium,.*', '^rda,.*', '^realtek,.*', '^remarkable,.*', '^renesas,.*', '^rervision,.*', '
^revotics,.*', '^rex,.*', '^richtek,.*', '^ricoh,.*', '^rikomagic,.*', '^riot,.*', '^riscv,.*', '^rockchip,.*', '^rocktech,.*', '^rohm,.*', '^ronbo,.*', '^roofull,.*', '^roseapplepi,.*', '^rve,.*', '^saef,.*', '^samsung,.*', '^samtec,.*', '^sancloud,.*', '^sandisk,.*', '^satoz,.*', '^sbs,.*', '^schindler,.*', '^seagate,.*', '^seeed,.*', '^seirobotics,.*', '^semtech,.*', '^senseair,.*', '^sensirion,.*', '^sensortek,.*', '^sercomm,.*', '^sff,.*', '^sgd,.*', '^sgmicro,.*', '^sgx,.*', '^sharp,.*', '^shift,.*', '^shimafuji,.*', '^shineworld,.*', '^shiratech,.*', '^si-en,.*', '^si-linux,.*', '^siemens,.*', '^sifive,.*', '^sigma,.*', '^sii,.*', '^sil,.*', '^silabs,.*', '^silan,.*', '^silead,.*', '^silergy,.*', '^silex-insight,.*', '^siliconfile,.*', '^siliconmitus,.*', '^silvaco,.*', '^simtek,.*', '^sinlinx,.*', '^sinovoip,.*', '^sinowealth,.*', '^sipeed,.*', '^sirf,.*', '^sis,.*', '^sitronix,.*', '^skov,.*', '^skyworks,.*', '^smartlabs,.*', '^smartrg,.*', '^smi,.*', '^smsc,.*', '^snps,.*'
, '^sochip,.*', '^socionext,.*', '^solidrun,.*', '^solomon,.*', '^sony,.*', '^sophgo,.*', '^sourceparts,.*', '^spansion,.*', '^sparkfun,.*', '^spinalhdl,.*', '^sprd,.*', '^square,.*', '^ssi,.*', '^sst,.*', '^sstar,.*', '^st,.*', '^st-ericsson,.*', '^starfive,.*', '^starry,.*', '^startek,.*', '^starterkit,.*', '^ste,.*', '^stericsson,.*', '^storlink,.*', '^storm,.*', '^storopack,.*', '^summit,.*', '^sunchip,.*', '^sundance,.*', '^sunplus,.*', '^supermicro,.*', '^swir,.*', '^syna,.*', '^synology,.*', '^synopsys,.*', '^tbs,.*', '^tbs-biometrics,.*', '^tcg,.*', '^tcl,.*', '^tcs,.*', '^tdo,.*', '^team-source-display,.*', '^technexion,.*', '^technologic,.*', '^techstar,.*', '^techwell,.*', '^teejet,.*', '^teltonika,.*', '^tempo,.*', '^terasic,.*', '^tesla,.*', '^tfc,.*', '^thead,.*', '^thine,.*', '^thingyjp,.*', '^thundercomm,.*', '^thwc,.*', '^ti,.*', '^tianma,.*', '^tlm,.*', '^tmt,.*', '^topeet,.*', '^topic,.*', '^toppoly,.*', '^topwise,.*', '^toradex,.*', '^toshiba,.*', '^toumaz,.*', '
^tpk,.*', '^tplink,.*', '^tpo,.*', '^tq,.*', '^transpeed,.*', '^traverse,.*', '^tronfy,.*', '^tronsmart,.*', '^truly,.*', '^tsd,.*', '^turing,.*', '^tyan,.*', '^u-blox,.*', '^u-boot,.*', '^ubnt,.*', '^ucrobotics,.*', '^udoo,.*', '^ufispace,.*', '^ugoos,.*', '^uni-t,.*', '^uniwest,.*', '^upisemi,.*', '^urt,.*', '^usi,.*', '^usr,.*', '^utoo,.*', '^v3,.*', '^vaisala,.*', '^vamrs,.*', '^variscite,.*', '^vdl,.*', '^vertexcom,.*', '^via,.*', '^vialab,.*', '^vicor,.*', '^videostrong,.*', '^virtio,.*', '^virtual,.*', '^vishay,.*', '^visionox,.*', '^vitesse,.*', '^vivante,.*', '^vivax,.*', '^vocore,.*', '^voipac,.*', '^voltafield,.*', '^vot,.*', '^vscom,.*', '^vxt,.*', '^wacom,.*', '^wanchanglong,.*', '^wand,.*', '^waveshare,.*', '^wd,.*', '^we,.*', '^welltech,.*', '^wetek,.*', '^wexler,.*', '^whwave,.*', '^wi2wi,.*', '^widora,.*', '^wiligear,.*', '^willsemi,.*', '^winbond,.*', '^wingtech,.*', '^winlink,.*', '^winstar,.*', '^wirelesstag,.*', '^wits,.*', '^wlf,.*', '^wm,.*', '^wobo,.*', '^x-p
owers,.*', '^xen,.*', '^xes,.*', '^xiaomi,.*', '^xillybus,.*', '^xingbangda,.*', '^xinpeng,.*', '^xiphera,.*', '^xlnx,.*', '^xnano,.*', '^xunlong,.*', '^xylon,.*', '^yadro,.*', '^yamaha,.*', '^yes-optoelectronics,.*', '^yic,.*', '^yiming,.*', '^ylm,.*', '^yna,.*', '^yones-toptech,.*', '^ys,.*', '^ysoft,.*', '^zarlink,.*', '^zealz,.*', '^zeitec,.*', '^zidoo,.*', '^zii,.*', '^zinitix,.*', '^zkmagic,.*', '^zte,.*', '^zyxel,.*', 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/vendor-prefixes.yaml#
arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dtb: mmc@ff370000: Unevaluated properties are not allowed ('ignore-pm-notify', 'supports-sd' were unexpected)
from schema $id: http://devicetree.org/schemas/mmc/rockchip-dw-mshc.yaml#
arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dtb: mmc@ff390000: Unevaluated properties are not allowed ('num-slots', 'supports-emmc' were unexpected)
from schema $id: http://devicetree.org/schemas/mmc/rockchip-dw-mshc.yaml#
arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dtb: gpu@ff400000: 'shadercores-supply' does not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/gpu/arm,mali-bifrost.yaml#
arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dtb: dsi@ff450000: Unevaluated properties are not allowed ('rockchip,lane-rate' was unexpected)
from schema $id: http://devicetree.org/schemas/display/rockchip/rockchip,dw-mipi-dsi.yaml#
arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dtb: panel@0: 'dsi,lanes' does not match any of the regexes: '^#.*', '^(at25|bm|devbus|dmacap|dsa|exynos|fsi[ab]|gpio-fan|gpio-key|gpio|gpmc|hdmi|i2c-gpio),.*', '^(keypad|m25p|max8952|max8997|max8998|mpmc),.*', '^(pinctrl-single|#pinctrl-single|PowerPC),.*', '^(pl022|pxa-mmc|rcar_sound|rotary-encoder|s5m8767|sdhci),.*', '^(simple-audio-card|st-plgpio|st-spics|ts),.*', '^100ask,.*', '^70mai,.*', '^8dev,.*', '^GEFanuc,.*', '^IBM,.*', '^ORCL,.*', '^SUNW,.*', '^[a-zA-Z0-9#_][a-zA-Z0-9+\-._@]{0,63}$', '^[a-zA-Z0-9+\-._]*@[0-9a-zA-Z,]*$', '^abb,.*', '^abilis,.*', '^abracon,.*', '^abt,.*', '^acbel,.*', '^acelink,.*', '^acer,.*', '^acme,.*', '^actions,.*', '^active-semi,.*', '^ad,.*', '^adafruit,.*', '^adapteva,.*', '^adaptrum,.*', '^adh,.*', '^adi,.*', '^adieng,.*', '^admatec,.*', '^advantech,.*', '^aeroflexgaisler,.*', '^aesop,.*', '^airoha,.*', '^al,.*', '^alcatel,.*', '^aldec,.*', '^alfa-network,.*', '^allegro,.*', '^alliedvision,.*', '^al
lo,.*', '^allwinner,.*', '^alphascale,.*', '^alps,.*', '^alt,.*', '^altr,.*', '^amarula,.*', '^amazon,.*', '^amcc,.*', '^amd,.*', '^amediatech,.*', '^amlogic,.*', '^ampere,.*', '^amphenol,.*', '^ampire,.*', '^ams,.*', '^amstaos,.*', '^analogix,.*', '^anbernic,.*', '^andestech,.*', '^anvo,.*', '^aosong,.*', '^apm,.*', '^apple,.*', '^aptina,.*', '^arasan,.*', '^archermind,.*', '^arcom,.*', '^arctic,.*', '^arcx,.*', '^aries,.*', '^arm,.*', '^armadeus,.*', '^arrow,.*', '^artesyn,.*', '^asahi-kasei,.*', '^asc,.*', '^asix,.*', '^aspeed,.*', '^asrock,.*', '^asteralabs,.*', '^asus,.*', '^atheros,.*', '^atlas,.*', '^atmel,.*', '^auo,.*', '^auvidea,.*', '^avago,.*', '^avia,.*', '^avic,.*', '^avnet,.*', '^awinic,.*', '^axentia,.*', '^axis,.*', '^azoteq,.*', '^azw,.*', '^baikal,.*', '^bananapi,.*', '^beacon,.*', '^beagle,.*', '^belling,.*', '^bhf,.*', '^bigtreetech,.*', '^bitmain,.*', '^blutek,.*', '^boe,.*', '^bosch,.*', '^boundary,.*', '^brcm,.*', '^broadmobi,.*', '^bsh,.*', '^bticino,.*', '^
buffalo,.*', '^bur,.*', '^bytedance,.*', '^calamp,.*', '^calao,.*', '^calaosystems,.*', '^calxeda,.*', '^canaan,.*', '^caninos,.*', '^capella,.*', '^cascoda,.*', '^catalyst,.*', '^cavium,.*', '^cdns,.*', '^cdtech,.*', '^cellwise,.*', '^ceva,.*', '^chargebyte,.*', '^checkpoint,.*', '^chefree,.*', '^chipidea,.*', '^chipone,.*', '^chipspark,.*', '^chongzhou,.*', '^chrontel,.*', '^chrp,.*', '^chunghwa,.*', '^chuwi,.*', '^ciaa,.*', '^cirrus,.*', '^cisco,.*', '^clockwork,.*', '^cloos,.*', '^cloudengines,.*', '^cnm,.*', '^cnxt,.*', '^colorfly,.*', '^compulab,.*', '^congatec,.*', '^coolpi,.*', '^coreriver,.*', '^corpro,.*', '^cortina,.*', '^cosmic,.*', '^crane,.*', '^creative,.*', '^crystalfontz,.*', '^csky,.*', '^csq,.*', '^ctera,.*', '^ctu,.*', '^cubietech,.*', '^cui,.*', '^cypress,.*', '^cyx,.*', '^cznic,.*', '^dallas,.*', '^dataimage,.*', '^davicom,.*', '^dell,.*', '^delta,.*', '^densitron,.*', '^denx,.*', '^devantech,.*', '^dfi,.*', '^dh,.*', '^difrnce,.*', '^digi,.*', '^digilent,.*',
'^dimonoff,.*', '^diodes,.*', '^dioo,.*', '^dlc,.*', '^dlg,.*', '^dlink,.*', '^dmo,.*', '^domintech,.*', '^dongwoon,.*', '^dptechnics,.*', '^dragino,.*', '^ds,.*', '^dserve,.*', '^dynaimage,.*', '^ea,.*', '^ebang,.*', '^ebbg,.*', '^ebs-systart,.*', '^ebv,.*', '^eckelmann,.*', '^edgeble,.*', '^edimax,.*', '^edt,.*', '^ees,.*', '^eeti,.*', '^einfochips,.*', '^eink,.*', '^elan,.*', '^element14,.*', '^elgin,.*', '^elida,.*', '^elimo,.*', '^elpida,.*', '^embedfire,.*', '^embest,.*', '^emlid,.*', '^emmicro,.*', '^empire-electronix,.*', '^emtrion,.*', '^enclustra,.*', '^endless,.*', '^ene,.*', '^energymicro,.*', '^engicam,.*', '^engleder,.*', '^epcos,.*', '^epfl,.*', '^epson,.*', '^esp,.*', '^est,.*', '^ettus,.*', '^eukrea,.*', '^everest,.*', '^everspin,.*', '^evervision,.*', '^exar,.*', '^excito,.*', '^exegin,.*', '^ezchip,.*', '^facebook,.*', '^fairchild,.*', '^fairphone,.*', '^faraday,.*', '^fascontek,.*', '^fastrax,.*', '^fcs,.*', '^feixin,.*', '^feiyang,.*', '^fii,.*', '^firefly,.*',
'^focaltech,.*', '^forlinx,.*', '^freebox,.*', '^freecom,.*', '^frida,.*', '^friendlyarm,.*', '^fsl,.*', '^fujitsu,.*', '^fxtec,.*', '^galaxycore,.*', '^gardena,.*', '^gateway,.*', '^gateworks,.*', '^gcw,.*', '^ge,.*', '^geekbuying,.*', '^gef,.*', '^gemei,.*', '^gemtek,.*', '^genesys,.*', '^geniatech,.*', '^giantec,.*', '^giantplus,.*', '^glinet,.*', '^globalscale,.*', '^globaltop,.*', '^gmt,.*', '^goldelico,.*', '^goodix,.*', '^google,.*', '^goramo,.*', '^gplus,.*', '^grinn,.*', '^grmn,.*', '^gumstix,.*', '^gw,.*', '^hannstar,.*', '^haochuangyi,.*', '^haoyu,.*', '^hardkernel,.*', '^hechuang,.*', '^hideep,.*', '^himax,.*', '^hirschmann,.*', '^hisi,.*', '^hisilicon,.*', '^hit,.*', '^hitex,.*', '^holt,.*', '^holtek,.*', '^honestar,.*', '^honeywell,.*', '^hoperf,.*', '^hoperun,.*', '^hp,.*', '^hpe,.*', '^hsg,.*', '^htc,.*', '^huawei,.*', '^hugsun,.*', '^hwacom,.*', '^hxt,.*', '^hycon,.*', '^hydis,.*', '^hynitron,.*', '^hynix,.*', '^hyundai,.*', '^i2se,.*', '^ibm,.*', '^icplus,.*', '^id
t,.*', '^iei,.*', '^iesy,.*', '^ifi,.*', '^ilitek,.*', '^imagis,.*', '^img,.*', '^imi,.*', '^inanbo,.*', '^incircuit,.*', '^indiedroid,.*', '^inet-tek,.*', '^infineon,.*', '^inforce,.*', '^ingenic,.*', '^ingrasys,.*', '^injoinic,.*', '^innocomm,.*', '^innolux,.*', '^inside-secure,.*', '^insignal,.*', '^inspur,.*', '^intel,.*', '^intercontrol,.*', '^invensense,.*', '^inventec,.*', '^inversepath,.*', '^iom,.*', '^irondevice,.*', '^isee,.*', '^isil,.*', '^issi,.*', '^ite,.*', '^itead,.*', '^itian,.*', '^ivo,.*', '^iwave,.*', '^jadard,.*', '^jasonic,.*', '^jdi,.*', '^jedec,.*', '^jesurun,.*', '^jethome,.*', '^jianda,.*', '^jide,.*', '^joz,.*', '^kam,.*', '^karo,.*', '^keithkoep,.*', '^keymile,.*', '^khadas,.*', '^kiebackpeter,.*', '^kinetic,.*', '^kingdisplay,.*', '^kingnovel,.*', '^kionix,.*', '^kobo,.*', '^kobol,.*', '^koe,.*', '^kontron,.*', '^kosagi,.*', '^kvg,.*', '^kyo,.*', '^lacie,.*', '^laird,.*', '^lamobo,.*', '^lantiq,.*', '^lattice,.*', '^lctech,.*', '^leadtek,.*', '^leez,.*'
, '^lego,.*', '^lemaker,.*', '^lenovo,.*', '^lg,.*', '^lgphilips,.*', '^libretech,.*', '^licheepi,.*', '^linaro,.*', '^lineartechnology,.*', '^linksprite,.*', '^linksys,.*', '^linutronix,.*', '^linux,.*', '^linx,.*', '^liteon,.*', '^litex,.*', '^lltc,.*', '^logicpd,.*', '^logictechno,.*', '^longcheer,.*', '^lontium,.*', '^loongmasses,.*', '^loongson,.*', '^lsi,.*', '^lunzn,.*', '^luxul,.*', '^lwn,.*', '^lxa,.*', '^m5stack,.*', '^macnica,.*', '^mantix,.*', '^mapleboard,.*', '^marantec,.*', '^marvell,.*', '^maxbotix,.*', '^maxim,.*', '^maxlinear,.*', '^mbvl,.*', '^mcube,.*', '^meas,.*', '^mecer,.*', '^mediatek,.*', '^megachips,.*', '^mele,.*', '^melexis,.*', '^melfas,.*', '^mellanox,.*', '^memsensing,.*', '^memsic,.*', '^menlo,.*', '^mentor,.*', '^meraki,.*', '^merrii,.*', '^methode,.*', '^micrel,.*', '^microchip,.*', '^microcrystal,.*', '^micron,.*', '^microsoft,.*', '^microsys,.*', '^mikroe,.*', '^mikrotik,.*', '^milkv,.*', '^miniand,.*', '^minix,.*', '^mips,.*', '^miramems,.*', '^m
itsubishi,.*', '^mitsumi,.*', '^mixel,.*', '^miyoo,.*', '^mntre,.*', '^mobileye,.*', '^modtronix,.*', '^moortec,.*', '^mosaixtech,.*', '^motorcomm,.*', '^motorola,.*', '^moxa,.*', '^mpl,.*', '^mps,.*', '^mqmaker,.*', '^mrvl,.*', '^mscc,.*', '^msi,.*', '^mstar,.*', '^mti,.*', '^multi-inno,.*', '^mundoreader,.*', '^murata,.*', '^mxic,.*', '^mxicy,.*', '^myir,.*', '^national,.*', '^nec,.*', '^neonode,.*', '^netgear,.*', '^netlogic,.*', '^netron-dy,.*', '^netronix,.*', '^netxeon,.*', '^neweast,.*', '^newhaven,.*', '^newvision,.*', '^nexbox,.*', '^nextthing,.*', '^ni,.*', '^nintendo,.*', '^nlt,.*', '^nokia,.*', '^nordic,.*', '^novatek,.*', '^novtech,.*', '^numonyx,.*', '^nutsboard,.*', '^nuvoton,.*', '^nvd,.*', '^nvidia,.*', '^nxp,.*', '^oceanic,.*', '^ocs,.*', '^oct,.*', '^okaya,.*', '^oki,.*', '^olimex,.*', '^olpc,.*', '^oneplus,.*', '^onie,.*', '^onion,.*', '^onnn,.*', '^ontat,.*', '^opalkelly,.*', '^openailab,.*', '^opencores,.*', '^openembed,.*', '^openpandora,.*', '^openrisc,.*', '
^option,.*', '^oranth,.*', '^orisetech,.*', '^ortustech,.*', '^osddisplays,.*', '^osmc,.*', '^ouya,.*', '^overkiz,.*', '^ovti,.*', '^oxsemi,.*', '^ozzmaker,.*', '^panasonic,.*', '^parade,.*', '^parallax,.*', '^pda,.*', '^pericom,.*', '^pervasive,.*', '^phicomm,.*', '^phytec,.*', '^picochip,.*', '^pine64,.*', '^pineriver,.*', '^pixcir,.*', '^plantower,.*', '^plathome,.*', '^plda,.*', '^plx,.*', '^ply,.*', '^pni,.*', '^pocketbook,.*', '^polaroid,.*', '^polyhex,.*', '^portwell,.*', '^poslab,.*', '^pov,.*', '^powertip,.*', '^powervr,.*', '^powkiddy,.*', '^primux,.*', '^probox2,.*', '^prt,.*', '^pulsedlight,.*', '^purism,.*', '^qca,.*', '^qcom,.*', '^qemu,.*', '^qi,.*', '^qiaodian,.*', '^qihua,.*', '^qishenglong,.*', '^qnap,.*', '^quanta,.*', '^radxa,.*', '^raidsonic,.*', '^ralink,.*', '^ramtron,.*', '^raspberrypi,.*', '^raydium,.*', '^rda,.*', '^realtek,.*', '^remarkable,.*', '^renesas,.*', '^rervision,.*', '^revotics,.*', '^rex,.*', '^richtek,.*', '^ricoh,.*', '^rikomagic,.*', '^riot,.
*', '^riscv,.*', '^rockchip,.*', '^rocktech,.*', '^rohm,.*', '^ronbo,.*', '^roofull,.*', '^roseapplepi,.*', '^rve,.*', '^saef,.*', '^samsung,.*', '^samtec,.*', '^sancloud,.*', '^sandisk,.*', '^satoz,.*', '^sbs,.*', '^schindler,.*', '^seagate,.*', '^seeed,.*', '^seirobotics,.*', '^semtech,.*', '^senseair,.*', '^sensirion,.*', '^sensortek,.*', '^sercomm,.*', '^sff,.*', '^sgd,.*', '^sgmicro,.*', '^sgx,.*', '^sharp,.*', '^shift,.*', '^shimafuji,.*', '^shineworld,.*', '^shiratech,.*', '^si-en,.*', '^si-linux,.*', '^siemens,.*', '^sifive,.*', '^sigma,.*', '^sii,.*', '^sil,.*', '^silabs,.*', '^silan,.*', '^silead,.*', '^silergy,.*', '^silex-insight,.*', '^siliconfile,.*', '^siliconmitus,.*', '^silvaco,.*', '^simtek,.*', '^sinlinx,.*', '^sinovoip,.*', '^sinowealth,.*', '^sipeed,.*', '^sirf,.*', '^sis,.*', '^sitronix,.*', '^skov,.*', '^skyworks,.*', '^smartlabs,.*', '^smartrg,.*', '^smi,.*', '^smsc,.*', '^snps,.*', '^sochip,.*', '^socionext,.*', '^solidrun,.*', '^solomon,.*', '^sony,.*', '^s
ophgo,.*', '^sourceparts,.*', '^spansion,.*', '^sparkfun,.*', '^spinalhdl,.*', '^sprd,.*', '^square,.*', '^ssi,.*', '^sst,.*', '^sstar,.*', '^st,.*', '^st-ericsson,.*', '^starfive,.*', '^starry,.*', '^startek,.*', '^starterkit,.*', '^ste,.*', '^stericsson,.*', '^storlink,.*', '^storm,.*', '^storopack,.*', '^summit,.*', '^sunchip,.*', '^sundance,.*', '^sunplus,.*', '^supermicro,.*', '^swir,.*', '^syna,.*', '^synology,.*', '^synopsys,.*', '^tbs,.*', '^tbs-biometrics,.*', '^tcg,.*', '^tcl,.*', '^tcs,.*', '^tdo,.*', '^team-source-display,.*', '^technexion,.*', '^technologic,.*', '^techstar,.*', '^techwell,.*', '^teejet,.*', '^teltonika,.*', '^tempo,.*', '^terasic,.*', '^tesla,.*', '^tfc,.*', '^thead,.*', '^thine,.*', '^thingyjp,.*', '^thundercomm,.*', '^thwc,.*', '^ti,.*', '^tianma,.*', '^tlm,.*', '^tmt,.*', '^topeet,.*', '^topic,.*', '^toppoly,.*', '^topwise,.*', '^toradex,.*', '^toshiba,.*', '^toumaz,.*', '^tpk,.*', '^tplink,.*', '^tpo,.*', '^tq,.*', '^transpeed,.*', '^traverse,.*', '
^tronfy,.*', '^tronsmart,.*', '^truly,.*', '^tsd,.*', '^turing,.*', '^tyan,.*', '^u-blox,.*', '^u-boot,.*', '^ubnt,.*', '^ucrobotics,.*', '^udoo,.*', '^ufispace,.*', '^ugoos,.*', '^uni-t,.*', '^uniwest,.*', '^upisemi,.*', '^urt,.*', '^usi,.*', '^usr,.*', '^utoo,.*', '^v3,.*', '^vaisala,.*', '^vamrs,.*', '^variscite,.*', '^vdl,.*', '^vertexcom,.*', '^via,.*', '^vialab,.*', '^vicor,.*', '^videostrong,.*', '^virtio,.*', '^virtual,.*', '^vishay,.*', '^visionox,.*', '^vitesse,.*', '^vivante,.*', '^vivax,.*', '^vocore,.*', '^voipac,.*', '^voltafield,.*', '^vot,.*', '^vscom,.*', '^vxt,.*', '^wacom,.*', '^wanchanglong,.*', '^wand,.*', '^waveshare,.*', '^wd,.*', '^we,.*', '^welltech,.*', '^wetek,.*', '^wexler,.*', '^whwave,.*', '^wi2wi,.*', '^widora,.*', '^wiligear,.*', '^willsemi,.*', '^winbond,.*', '^wingtech,.*', '^winlink,.*', '^winstar,.*', '^wirelesstag,.*', '^wits,.*', '^wlf,.*', '^wm,.*', '^wobo,.*', '^x-powers,.*', '^xen,.*', '^xes,.*', '^xiaomi,.*', '^xillybus,.*', '^xingbangda,.*'
, '^xinpeng,.*', '^xiphera,.*', '^xlnx,.*', '^xnano,.*', '^xunlong,.*', '^xylon,.*', '^yadro,.*', '^yamaha,.*', '^yes-optoelectronics,.*', '^yic,.*', '^yiming,.*', '^ylm,.*', '^yna,.*', '^yones-toptech,.*', '^ys,.*', '^ysoft,.*', '^zarlink,.*', '^zealz,.*', '^zeitec,.*', '^zidoo,.*', '^zii,.*', '^zinitix,.*', '^zkmagic,.*', '^zte,.*', '^zyxel,.*', 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/vendor-prefixes.yaml#
arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dtb: /dsi@ff450000/panel@0: failed to match any schema with compatible: ['simple-panel-dsi']
arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dtb: /fiq-debugger: failed to match any schema with compatible: ['rockchip,fiq-debugger']
arch/arm64/boot/dts/rockchip/px30-iesy-eva-mi-v2.dtb: user-buttons: '#address-cells', '#size-cells', 'user-button-1', 'user-button-2' do not match any of the regexes: '^(button|event|key|switch|(button|event|key|switch)-[a-z0-9-]+|[a-z0-9-]+-(button|event|key|switch))$', 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/input/gpio-keys.yaml#
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net-next v5 00/10] Support ICSSG-based Ethernet on AM65x SR1.0 devices
From: Simon Horman @ 2024-03-20 16:21 UTC (permalink / raw)
To: Diogo Ivo
Cc: danishanwar, rogerq, davem, edumazet, kuba, pabeni, andrew,
dan.carpenter, jacob.e.keller, robh, robh+dt,
krzysztof.kozlowski+dt, conor+dt, vigneshr, wsa+renesas,
hkallweit1, arnd, vladimir.oltean, linux-arm-kernel, netdev,
devicetree, jan.kiszka
In-Reply-To: <20240320144234.313672-1-diogo.ivo@siemens.com>
On Wed, Mar 20, 2024 at 02:42:22PM +0000, Diogo Ivo wrote:
> Hello,
>
> This series extends the current ICSSG-based Ethernet driver to support
> AM65x Silicon Revision 1.0 devices.
>
> Notable differences between the Silicon Revisions are that there is
> no TX core in SR1.0 with this being handled by the firmware, requiring
> extra DMA channels to manage communication with the firmware (with the
> firmware being different as well) and in the packet classifier.
>
> The motivation behind it is that a significant number of Siemens
> devices containing SR1.0 silicon have been deployed in the field
> and need to be supported and updated to newer kernel versions
> without losing functionality.
>
> This series is based on TI's 5.10 SDK [1].
>
> The fourth version of this patch series can be found in [2].
>
> Detailed descriptions of the changes in this series can be found in
> each commit's message.
>
> Both of the problems mentioned in v4 have been addressed by disabling
> those functionalities, meaning that this driver currently only supports
> one TX queue and does not support a 100Mbit/s half-duplex connection.
> The removal of these features has been commented in the appropriate
> locations in the code.
>
> [1]: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/?h=ti-linux-5.10.y
> [2]: https://lore.kernel.org/netdev/20240305114045.388893-1-diogo.ivo@siemens.com/
## Form letter - net-next-closed
(original text from Jakub)
The merge window for v6.9 has begun and therefore net-next is closed
for new drivers, features, code refactoring and optimizations.
We are currently accepting bug fixes only.
Please repost when net-next reopens after March 25th.
RFC patches sent for review only are welcome at any time.
See: https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#development-cycle
--
pw-bot: defer
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/3] dt-bindings: mtd: atmel-nand: add deprecated bindings
From: Conor Dooley @ 2024-03-20 16:25 UTC (permalink / raw)
To: Balamanikandan Gunasundar
Cc: Rob Herring, Conor Dooley, linux-kernel, Vignesh Raghavendra,
Alexandre Belloni, devicetree, Richard Weinberger, Claudiu Beznea,
linux-mtd, Krzysztof Kozlowski, Miquel Raynal, linux-arm-kernel
In-Reply-To: <20240320-linux-next-nand-yaml-v1-3-2d2495363e88@microchip.com>
[-- Attachment #1.1: Type: text/plain, Size: 7969 bytes --]
On Wed, Mar 20, 2024 at 11:22:09AM +0530, Balamanikandan Gunasundar wrote:
> Add nand bindings for legacy nand controllers. These bindings are not used
> with the new device trees. This is still maintained to support legacy dt
> bindings.
>
> Signed-off-by: Balamanikandan Gunasundar <balamanikandan.gunasundar@microchip.com>
> ---
> .../bindings/mtd/atmel-nand-deprecated.yaml | 156 +++++++++++++++++++++
> .../devicetree/bindings/mtd/atmel-nand.txt | 116 ---------------
> 2 files changed, 156 insertions(+), 116 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand-deprecated.yaml b/Documentation/devicetree/bindings/mtd/atmel-nand-deprecated.yaml
> new file mode 100644
> index 000000000000..c8922ab0f1d5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/atmel-nand-deprecated.yaml
Node name matching the devices please.
> @@ -0,0 +1,156 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mtd/atmel-nand-deprecated.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Atmel NAND flash controller deprecated bindings
/stuff/linux-dt/Documentation/devicetree/bindings/mtd/atmel-nand-deprecated.yaml: title: 'Atmel NAND flash controller deprecated bindings' should not be valid under {'pattern': '([Bb]inding| [Ss]chema)'}
hint: Everything is a binding/schema, no need to say it. Describe what hardware the binding is for.
> +
> +maintainers:
> + - Balamanikandan Gunasundar <balamanikandan.gunasundar@microchip.com>
> +
> +description: |
> + This should not be used in the new device trees.
If these should not be used in new files, where are the replacement
bindings for the three devices listed here? I think, rather than being
deprecated, these are the only bindings for these devices and what you
actually want to say here is that these should not be used for /new
devices/. I'd drop mention of deprecation from the title as these
bindings are the only ones for this hardware AFAICT and just say that
new devices should be documented in $new_file.
> +properties:
> + compatible:
> + enum:
> + - atmel,at91rm9200-nand
> + - atmel,sama5d2-nand
> + - atmel,sama5d4-nand
> +
> + reg:
Missing constraints.
> + description:
> + should specify localbus address and size used for the chip, and
> + hardware ECC controller if available. If the hardware ECC is PMECC,
> + it should contain address and size for PMECC and PMECC Error Location
> + controller. The PMECC lookup table address and size in ROM is
> + optional. If not specified, driver will build it in runtime.
> +
> + atmel,nand-addr-offset:
> + description:
> + offset for the address latch.
> + $ref: /schemas/types.yaml#/definitions/uint32
Missing constraints.
> +
> + atmel,nand-cmd-offset:
> + description:
> + offset for the command latch.
> + $ref: /schemas/types.yaml#/definitions/uint32
Missing contraints.
> +
> + "#address-cells":
> + description:
> + Must be present if the device has sub-nodes representing partitions
Does this binding even allow partition child nodes? Hint: it doesn't.
> + "#size-cells":
> + description:
> + Must be present if the device has sub-nodes representing partitions.
> +
> + gpios:
> + description:
> + specifies the gpio pins to control the NAND device. detect is an
> + optional gpio and may be set to 0 if not present.
Missing constraints (and maybe a type too? I dunno if "gpios" has a
special case in the -gpios regexes).
> + atmel,nand-has-dma:
> + description:
> + support dma transfer for nand read/write.
> + $ref: /schemas/types.yaml#/definitions/flag
> +
> + atmel,has-pmecc:
> + description:
> + enable Programmable Multibit ECC hardware, capable of BCH encoding
> + and decoding, on devices where it is present.
> + $ref: /schemas/types.yaml#/definitions/flag
> +
> + nand-on-flash-bbt:
> + description:
> + enable on flash bbt option if not present false
> + $ref: /schemas/types.yaml#/definitions/flag
> +
> + nand-ecc-mode:
Missing a default since this is optional.
> + description:
> + operation mode of the NAND ecc mode, soft by default. Supported
> + enum:
> + [none, soft, hw, hw_syndrome, hw_oob_first, soft_bch]
> + $ref: /schemas/types.yaml#/definitions/string
> +
> + atmel,pmecc-cap:
> + description:
> + error correct capability for Programmable Multibit ECC Controller. If
> + the compatible string is "atmel,sama5d2-nand", 32 is also valid.
> + enum:
> + [2, 4, 8, 12, 24]
You're missing an extra permitted value for the sama5d2.
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
> + atmel,pmecc-sector-size:
Missing a default since this is optional.
> + description:
> + sector size for ECC computation.
> + enum:
> + [512, 1024]
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
> + atmel,pmecc-lookup-table-offset:
Missing a default since this is optional.
> + description:
> + includes two offsets of lookup table in ROM for different sector
> + size. First one is for sector size 512, the next is for sector size
> + 1024. If not specified, driver will build the table in runtime.
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> +
> + nand-bus-width:
> + description:
> + nand bus width
> + enum:
> + [8, 16]
Missing a default of 8 here.
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
You're missing the optional child node for the "nand flash controller" on
sama5d2.
> +required:
> + - compatible
> + - reg
> + - atmel,nand-addr-offset
> + - atmel,nand-cmd-offset
> + - "#address-cells"
> + - "#size-cells"
> + - gpios
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + nand0: nand@40000000,0 {
Drop the unused node name.
> + compatible = "atmel,at91rm9200-nand";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0x40000000 0x10000000
> + 0xffffe800 0x200>;
> + atmel,nand-addr-offset = <21>; /* ale */
> + atmel,nand-cmd-offset = <22>; /* cle */
> + nand-on-flash-bbt;
> + nand-ecc-mode = "soft";
> + gpios = <&pioC 13 0 /* rdy */
> + &pioC 14 0 /* nce */
> + 0 /* cd */
> + >;
Please follow the coding style rather than copy-paste from the text
based binding. Applies to both examples. An example with the nfc would
be more helpful than two bindings for the same device.
Thanks,
Conor.
> + };
> + - |
> + /* for PMECC supported chips */
> + nand1@40000000 {
> + compatible = "atmel,at91rm9200-nand";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0x40000000 0x10000000 /* bus addr & size */
> + 0xffffe000 0x00000600 /* PMECC addr & size */
> + 0xffffe600 0x00000200 /* PMECC ERRLOC addr & size */
> + 0x00100000 0x00100000>; /* ROM addr & size */
> +
> + atmel,nand-addr-offset = <21>; /* ale */
> + atmel,nand-cmd-offset = <22>; /* cle */
> + nand-on-flash-bbt;
> + nand-ecc-mode = "hw";
> + atmel,has-pmecc; /* enable PMECC */
> + atmel,pmecc-cap = <2>;
> + atmel,pmecc-sector-size = <512>;
> + atmel,pmecc-lookup-table-offset = <0x8000 0x10000>;
> + gpios = <&pioD 5 0 /* rdy */
> + &pioD 4 0 /* nce */
> + 0 /* cd */
> + >;
> + };
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: mtd: atmel-nand: convert txt to yaml
From: Conor Dooley @ 2024-03-20 16:35 UTC (permalink / raw)
To: Balamanikandan Gunasundar
Cc: Rob Herring, Conor Dooley, linux-kernel, Vignesh Raghavendra,
Alexandre Belloni, devicetree, Richard Weinberger, Claudiu Beznea,
linux-mtd, Krzysztof Kozlowski, Miquel Raynal, linux-arm-kernel
In-Reply-To: <20240320-linux-next-nand-yaml-v1-1-2d2495363e88@microchip.com>
[-- Attachment #1.1: Type: text/plain, Size: 7656 bytes --]
On Wed, Mar 20, 2024 at 11:22:07AM +0530, Balamanikandan Gunasundar wrote:
> Convert text to yaml for atmel nand controller
>
> Signed-off-by: Balamanikandan Gunasundar <balamanikandan.gunasundar@microchip.com>
> ---
> .../devicetree/bindings/mtd/atmel-nand.txt | 50 -------
> .../devicetree/bindings/mtd/atmel-nand.yaml | 166 +++++++++++++++++++++
> MAINTAINERS | 2 +-
> 3 files changed, 167 insertions(+), 51 deletions(-)
> diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.yaml b/Documentation/devicetree/bindings/mtd/atmel-nand.yaml
> new file mode 100644
> index 000000000000..a5482d292293
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/atmel-nand.yaml
Filename matching a compatible please.
> @@ -0,0 +1,166 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mtd/atmel-nand.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Atmel NAND flash controller
> +
> +maintainers:
> + - Balamanikandan Gunasundar <balamanikandan.gunasundar@microchip.com>
> +
> +description: |
> + The NAND flash controller node should be defined under the EBI bus (see
> + Documentation/devicetree/bindings/memory-controllers/atmel,ebi.txt|yaml).
text|yaml?
> + One or several NAND devices can be defined under this NAND controller.
> + The NAND controller might be connected to an ECC engine.
> +
> +properties:
> + compatible:
> + oneOf:
> + - items:
> + - enum:
This is just an enum, drop the items and oneof.
> + - atmel,at91rm9200-nand-controller
> + - atmel,at91sam9260-nand-controller
> + - atmel,at91sam9261-nand-controller
> + - atmel,at91sam9g45-nand-controller
> + - atmel,sama5d3-nand-controller
> + - microchip,sam9x60-nand-controller
> +
> + ranges:
> + description: empty ranges property to forward EBI ranges definitions.
> +
> + ecc-engine:
> + description:
> + phandle to the PMECC block. Only meaningful if the SoC embeds a PMECC
> + engine.
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - atmel,at91rm9200-nand-controller
> + - atmel,at91sam9260-nand-controller
> + - atmel,at91sam9261-nand-controller
> + - atmel,at91sam9g45-nand-controller
> + - atmel,sama5d3-nand-controller
> + - microchip,sam9x60-nand-controller
> + then:
> + properties:
> + "#address-cells":
> + const: 2
> +
> + "#size-cells":
> + const: 1
Why is this in an if? Isn't this all of the devices in the binding?
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: atmel,sama5d3-nand-controller
> + then:
> + properties:
> + atmel,nfc-io:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: phandle to the NFC IO block.
> +
> + atmel,nfc-sram:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: phandle to the NFC SRAM block
Please define the properties at the top level and use if statements to
constrain them.
> +
> +required:
> + - compatible
> + - ranges
> + - "#address-cells"
> + - "#size-cells"
> +
> +patternProperties:
> + "^nand@[a-f0-9]$":
> + type: object
> + $ref: nand-chip.yaml#
> + description:
> + NAND chip bindings. All generic properties described in
> + Documentation/devicetree/bindings/mtd/{common,nand}.txt also apply to
> + the NAND device node, and NAND partitions should be defined under the
> + NAND node as described in
> + Documentation/devicetree/bindings/mtd/partition.txt.
These files do not exist.
> + properties:
> + reg:
> + minItems: 1
> + description:
> + describes the CS lines assigned to the NAND device. If the NAND device
> + exposes multiple CS lines (multi-dies chips), your reg property will
> + contain X tuples of 3 entries.
The "if" here is not accurate. Your binding mandates there being 3
entries.
> + reg = <0x3 0x0 0x800000>;
> + 1st entry - the CS line this NAND chip is connected to
> + 2nd entry - the base offset of the memory region assigned to this
> + device (always 0)
> + 3rd entry - the memory region size (always 0x800000)
> +
> + rb-gpios:
> + description:
> + the GPIO(s) used to check the Ready/Busy status of the NAND.
> +
> + cs-gpios:
> + description:
> + the GPIO(s) used to control the CS line.
> +
> + det-gpios:
> + description:
> + the GPIO used to detect if a Smartmedia Card is present.
> +
> + "atmel,rb":
> + description:
> + an integer identifying the native Ready/Busy pin. Only meaningful
> + on sama5 SoCs.
Then please constrain it to sama5 SoCs only :)
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + nfc_io: nfc-io@70000000 {
> + compatible = "atmel,sama5d3-nfc-io", "syscon";
> + reg = <0x70000000 0x8000000>;
> + };
What's this got to do with the binding?
> + pmecc: ecc-engine@ffffc070 {
> + compatible = "atmel,at91sam9g45-pmecc";
> + reg = <0xffffc070 0x490>,
> + <0xffffc500 0x100>;
> + };
> +
> + ebi: ebi@10000000 {
Drop the unused label.
Same applies here, read the coding style about how to write dts nodes
please.
Thanks,
Conor.
> + compatible = "atmel,sama5d3-ebi";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + atmel,smc = <&hsmc>;
> + reg = <0x10000000 0x10000000
> + 0x40000000 0x30000000>;
> + ranges = <0x0 0x0 0x10000000 0x10000000
> + 0x1 0x0 0x40000000 0x10000000
> + 0x2 0x0 0x50000000 0x10000000
> + 0x3 0x0 0x60000000 0x10000000>;
> + clocks = <&mck>;
> +
> + nandflash_controller: nandflash-controller {
> + compatible = "atmel,sama5d3-nand-controller";
> + ecc-engine = <&pmecc>;
> + #address-cells = <2>;
> + #size-cells = <1>;
> + ranges;
> +
> + nand@3 {
> + reg = <0x3 0x0 0x800000>;
> + atmel,rb = <0>;
> +
> + /*
> + * Put generic NAND/MTD properties and
> + * subnodes here.
> + */
> + };
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b6582bd3eb2c..3f2a6756223f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -14503,7 +14503,7 @@ MICROCHIP NAND DRIVER
> M: Balamanikandan Gunasundar <balamanikandan.gunasundar@microchip.com>
> L: linux-mtd@lists.infradead.org
> S: Supported
> -F: Documentation/devicetree/bindings/mtd/atmel-nand.txt
> +F: Documentation/devicetree/bindings/mtd/atmel-*.yaml
> F: drivers/mtd/nand/raw/atmel/*
>
> MICROCHIP OTPC DRIVER
>
> --
> 2.25.1
>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 09/11] regulator: tps6594-regulator: Add TI TPS65224 PMIC regulators
From: Mark Brown @ 2024-03-20 16:38 UTC (permalink / raw)
To: Bhargav Raviprakash
Cc: linux-kernel, m.nirmaladevi, lee, robh+dt, krzysztof.kozlowski+dt,
conor+dt, jpanis, devicetree, arnd, gregkh, lgirdwood,
linus.walleij, linux-gpio, linux-arm-kernel, nm, vigneshr, kristo,
eblanc
In-Reply-To: <20240320102559.464981-10-bhargav.r@ltts.com>
[-- Attachment #1.1: Type: text/plain, Size: 448 bytes --]
On Wed, Mar 20, 2024 at 03:55:57PM +0530, Bhargav Raviprakash wrote:
> +static struct tps6594_regulator_irq_type tps65224_buck1_irq_types[] = {
> + { TPS65224_IRQ_NAME_BUCK1_UVOV, "BUCK1", "voltage out of range",
> + REGULATOR_EVENT_OVER_VOLTAGE_WARN },
> +};
These all look like they should be _REGULATION_OUT given that the
interrupt names are _UVOV which look like they could be either under or
over voltage.
Otherwise this all looks good.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 1/5] dt-bindings: misc: Add mikrobus-connector
From: Ayush Singh @ 2024-03-20 16:39 UTC (permalink / raw)
To: Andrew Lunn
Cc: Vaishnav Achath, Michael Walle, Krzysztof Kozlowski, open list,
jkridner, robertcnelson, lorforlinux, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Nishanth Menon,
Vignesh Raghavendra, Tero Kristo, Derek Kiernan, Dragan Cvetic,
Arnd Bergmann, Greg Kroah-Hartman, Mark Brown, Johan Hovold,
Alex Elder,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/TEXAS INSTRUMENTS K3 ARCHITECTURE,
open list:SPI SUBSYSTEM, moderated list:GREYBUS SUBSYSTEM,
Vaishnav M A
In-Reply-To: <f53cd006-5eb0-47f2-8f84-e7915154f12d@lunn.ch>
On 3/20/24 01:02, Andrew Lunn wrote:
>> Yes, after discussion with Vaishnav and trying to brainstorm some way to do
>> the same thing with dt overlays, it seems that trying to use dt overlays
>> will mean need to have completely separate implementation of mikroBUS for
>> local ports and mikroBUS over greybus.
> Could you explain why please?
>
> Are greybus I2C bus masters different from physical I2C bus masters?
> Are greybus SPI bus masters different from physical SPI bus masters?
Well, they are virtual, so they are not declared in the device tree. I
have linked the greybus i2c implementation. It basically allocates an
i2c_adpater and then adds it using `i2c_add_adapter` method. This
adapter can then be passed to say mikroBUS driver where it can be used
as a normal i2c_adapter, and we can register the device to it.
>> Additionally, trying to put dt overlays in EEPROM would mean they
>> will be incompatible with use in local ports and vice versa.
> I don't think you need to put the DT overlay in the EEPROM. All you
> need to do is translate the manifest into DT for those simple devices
> which can be described by the limited manifest format. For more
> complex devices, you use the ID to go find a DT fragment which
> describes the board, and skip the manifest to DT transformation.
>
> Andrew
I am not familiar enough to know if the device tree can work with
virtual devices created by greybus subsystem.
Maybe the problem stems from the fact that mikroBUS does not have a
physical controller (and my inability to explain the patch properly).
However, the purpose of this patchset is to in fact provide a virtual
mikroBUS controller to allow us to register a mikroBUS addon board
described by board_info struct similar to how it is possible to create
and register an i2c device on an i2c adapter using
`i2c_new_client_device` or spi device using `spi_new_device`. The
manifest is used to populate this board_info struct, but it will be
possible to use something other than mikroBUS manifest if someone wants
to. I can make the necessary adjustments by moving manifest support to
its own config option.
Link:
https://elixir.bootlin.com/linux/latest/source/drivers/staging/greybus/i2c.c#L230
Greybus i2c
Ayush Singh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: mtd: atmel-nand: add atmel pmecc
From: Conor Dooley @ 2024-03-20 16:40 UTC (permalink / raw)
To: Balamanikandan Gunasundar
Cc: Rob Herring, Conor Dooley, linux-kernel, Vignesh Raghavendra,
Alexandre Belloni, devicetree, Richard Weinberger, Claudiu Beznea,
linux-mtd, Krzysztof Kozlowski, Miquel Raynal, linux-arm-kernel
In-Reply-To: <20240320-linux-next-nand-yaml-v1-2-2d2495363e88@microchip.com>
[-- Attachment #1.1: Type: text/plain, Size: 2663 bytes --]
On Wed, Mar 20, 2024 at 11:22:08AM +0530, Balamanikandan Gunasundar wrote:
> Add bindings for programmable multibit error correction code controller
> (PMECC).
>
> Signed-off-by: Balamanikandan Gunasundar <balamanikandan.gunasundar@microchip.com>
> diff --git a/Documentation/devicetree/bindings/mtd/atmel-pmecc.yaml b/Documentation/devicetree/bindings/mtd/atmel-pmecc.yaml
Filename matching a compatible please.
> new file mode 100644
> index 000000000000..872401e9dda3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/atmel-pmecc.yaml
> @@ -0,0 +1,58 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mtd/atmel-pmecc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip pmecc controller
> +
> +maintainers:
> + - Balamanikandan Gunasundar <balamanikandan.gunasundar@microchip.com>
> +
> +description: |
> + Bindings for microchip Programmable Multibit Error Correction Code
> + Controller (PMECC). pmecc is a programmable BCH encoder/decoder. This
> + block is passed as the value to the "ecc-engine" property of microchip
> + nand flash controller node.
> +
> +properties:
> + compatible:
> + oneOf:
> + - enum:
> + - atmel,at91sam9g45-pmecc
> + - atmel,sama5d2-pmecc
> + - atmel,sama5d4-pmecc
> + - microchip,sam9x60-pmecc
> + - microchip,sam9x7-pmecc
> + - items:
> + - const: microchip,sam9x60-pmecc
> + - const: atmel,at91sam9g45-pmecc
> +
> + reg:
> + description:
> + The first should point to the PMECC block. The second should point to the
> + PMECC_ERRLOC block.
Constraints please. In fact, describe it as an items list and then you
don't need constraints or a free-form text explanation of what each
entry is :)
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: microchip,sam9x7-pmecc
> + then:
> + properties:
> + clocks:
> + description:
> + The clock source for pmecc controller
> + maxItems: 1
Please define the property at the top level and constrain it on a per
device basis.
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + pmecc: ecc-engine@ffffc070 {
Drop the unused label please.
Thanks,
Conor.
> + compatible = "microchip,sam9x7-pmecc";
> + reg = <0xffffe000 0x300>,
> + <0xffffe600 0x100>;
> + clocks = <&pmc 2 48>;
> + };
>
> --
> 2.25.1
>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 2/3] arm64: Provide an AMU-based version of arch_freq_get_on_cpu
From: Sumit Gupta @ 2024-03-20 16:43 UTC (permalink / raw)
To: Beata Michalska, linux-arm-kernel, ionela.voinescu
Cc: sudeep.holla, will, catalin.marinas, vincent.guittot, yang,
lihuisong, vanshikonda, linux-kernel@vger.kernel.org, linux-tegra
In-Reply-To: <20240312083431.3239989-3-beata.michalska@arm.com>
On 12/03/24 14:04, Beata Michalska wrote:
> External email: Use caution opening links or attachments
>
>
> With the Frequency Invariance Engine (FIE) being already wired up with
> sched tick and making use of relevant (core counter and constant
> counter) AMU counters, getting the current frequency for a given CPU
> on supported platforms can be achieved by utilizing the frequency scale
> factor which reflects an average CPU frequency for the last tick period
> length.
>
> The solution is partially based on APERF/MPERF implementation of
> arch_freq_get_on_cpu.
>
> Suggested-by: Ionela Voinescu <ionela.voinescu@arm.com>
> Signed-off-by: Beata Michalska <beata.michalska@arm.com>
> ---
> arch/arm64/kernel/topology.c | 103 +++++++++++++++++++++++++++++++----
> 1 file changed, 92 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
> index 1a2c72f3e7f8..42cb19c31719 100644
> --- a/arch/arm64/kernel/topology.c
> +++ b/arch/arm64/kernel/topology.c
> @@ -17,6 +17,8 @@
> #include <linux/cpufreq.h>
> #include <linux/init.h>
> #include <linux/percpu.h>
> +#include <linux/sched/isolation.h>
> +#include <linux/seqlock_types.h>
>
> #include <asm/cpu.h>
> #include <asm/cputype.h>
> @@ -88,18 +90,31 @@ int __init parse_acpi_topology(void)
> * initialized.
> */
> static DEFINE_PER_CPU_READ_MOSTLY(unsigned long, arch_max_freq_scale) = 1UL << (2 * SCHED_CAPACITY_SHIFT);
> -static DEFINE_PER_CPU(u64, arch_const_cycles_prev);
> -static DEFINE_PER_CPU(u64, arch_core_cycles_prev);
> static cpumask_var_t amu_fie_cpus;
>
> +struct amu_cntr_sample {
> + u64 arch_const_cycles_prev;
> + u64 arch_core_cycles_prev;
> + unsigned long last_update;
> + seqcount_t seq;
> +};
> +
> +static DEFINE_PER_CPU_SHARED_ALIGNED(struct amu_cntr_sample, cpu_amu_samples) = {
> + .seq = SEQCNT_ZERO(cpu_amu_samples.seq)
> +};
> +
> void update_freq_counters_refs(void)
> {
> - this_cpu_write(arch_core_cycles_prev, read_corecnt());
> - this_cpu_write(arch_const_cycles_prev, read_constcnt());
> + struct amu_cntr_sample *amu_sample = this_cpu_ptr(&cpu_amu_samples);
> +
> + amu_sample->arch_core_cycles_prev = read_corecnt();
> + amu_sample->arch_const_cycles_prev = read_constcnt();
> }
>
> static inline bool freq_counters_valid(int cpu)
> {
> + struct amu_cntr_sample *amu_sample = per_cpu_ptr(&cpu_amu_samples, cpu);
> +
> if ((cpu >= nr_cpu_ids) || !cpumask_test_cpu(cpu, cpu_present_mask))
> return false;
>
> @@ -108,8 +123,8 @@ static inline bool freq_counters_valid(int cpu)
> return false;
> }
>
> - if (unlikely(!per_cpu(arch_const_cycles_prev, cpu) ||
> - !per_cpu(arch_core_cycles_prev, cpu))) {
> + if (unlikely(!amu_sample->arch_const_cycles_prev ||
> + !amu_sample->arch_core_cycles_prev)) {
> pr_debug("CPU%d: cycle counters are not enabled.\n", cpu);
> return false;
> }
> @@ -152,20 +167,27 @@ void freq_inv_set_max_ratio(int cpu, u64 max_rate)
>
> static void amu_scale_freq_tick(void)
> {
> + struct amu_cntr_sample *amu_sample = this_cpu_ptr(&cpu_amu_samples);
> u64 prev_core_cnt, prev_const_cnt;
> u64 core_cnt, const_cnt, scale;
>
> - prev_const_cnt = this_cpu_read(arch_const_cycles_prev);
> - prev_core_cnt = this_cpu_read(arch_core_cycles_prev);
> + prev_const_cnt = amu_sample->arch_const_cycles_prev;
> + prev_core_cnt = amu_sample->arch_core_cycles_prev;
> +
> + write_seqcount_begin(&amu_sample->seq);
>
> update_freq_counters_refs();
>
> - const_cnt = this_cpu_read(arch_const_cycles_prev);
> - core_cnt = this_cpu_read(arch_core_cycles_prev);
> + const_cnt = amu_sample->arch_const_cycles_prev;
> + core_cnt = amu_sample->arch_core_cycles_prev;
>
> + /*
> + * This should not happen unless the AMUs have been reset and the
> + * counter values have not been resroted - unlikely
> + */
> if (unlikely(core_cnt <= prev_core_cnt ||
> const_cnt <= prev_const_cnt))
> - return;
> + goto leave;
>
> /*
> * /\core arch_max_freq_scale
> @@ -182,6 +204,10 @@ static void amu_scale_freq_tick(void)
>
> scale = min_t(unsigned long, scale, SCHED_CAPACITY_SCALE);
> this_cpu_write(arch_freq_scale, (unsigned long)scale);
> +
> + amu_sample->last_update = jiffies;
> +leave:
> + write_seqcount_end(&amu_sample->seq);
> }
>
> static struct scale_freq_data amu_sfd = {
> @@ -189,6 +215,61 @@ static struct scale_freq_data amu_sfd = {
> .set_freq_scale = amu_scale_freq_tick,
> };
>
> +#define AMU_SAMPLE_EXP_MS 20
> +
> +unsigned int arch_freq_get_on_cpu(int cpu)
> +{
> + struct amu_cntr_sample *amu_sample;
> + unsigned long last_update;
> + unsigned int seq;
> + unsigned int freq;
> + u64 scale;
> +
> + if (!cpumask_test_cpu(cpu, amu_fie_cpus) || !arch_scale_freq_ref(cpu))
> + return 0;
> +
> +retry:
> + amu_sample = per_cpu_ptr(&cpu_amu_samples, cpu);
> +
> + do {
> + seq = raw_read_seqcount_begin(&amu_sample->seq);
> + last_update = amu_sample->last_update;
> + } while (read_seqcount_retry(&amu_sample->seq, seq));
> +
> + /*
> + * For those CPUs that are in full dynticks mode,
> + * and those that have not seen tick for a while
> + * try an alternative source for the counters (and thus freq scale),
> + * if available for given policy
> + */
> + if (time_is_before_jiffies(last_update + msecs_to_jiffies(AMU_SAMPLE_EXP_MS))) {
> + struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
> + int ref_cpu = nr_cpu_ids;
> +
> + if (cpumask_intersects(housekeeping_cpumask(HK_TYPE_TICK),
> + policy->cpus))
> + ref_cpu = cpumask_nth_and(cpu, policy->cpus,
> + housekeeping_cpumask(HK_TYPE_TICK));
> +
This is looking for any other HK CPU within same policy for counters.
AFAIU, cpumask_nth_and() will return small_cpumask_bits/nr_cpu_ids
if the number of bits in both masks is different. Could you check
again if the current change is fine or needs something like below.
BTW, we have one CPU per policy.
cpumask_and(&mask, policy->cpus, housekeeping_cpumask(HK_TYPE_TICK));
retry:
....
cpumask_andnot(&mask, &mask, cpumask_of(cpu));
ref_cpu = cpumask_any(&mask);
Thank you,
Sumit Gupta
> + cpufreq_cpu_put(policy);
> + if (ref_cpu >= nr_cpu_ids || ref_cpu == cpu)
> + /* No alternative to pull info from */
> + return 0;
> + cpu = ref_cpu;
> + goto retry;
> + }
> + /*
> + * Reversed computation to the one used to determine
> + * the arch_freq_scale value
> + * (see amu_scale_freq_tick for details)
> + */
> + scale = arch_scale_freq_capacity(cpu);
> + freq = scale * arch_scale_freq_ref(cpu);
> + freq >>= SCHED_CAPACITY_SHIFT;
> +
> + return freq;
> +}
> +
> static void amu_fie_setup(const struct cpumask *cpus)
> {
> int cpu;
> --
> 2.25.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/3] Add support for AArch64 AMUv1-based arch_freq_get_on_cpu
From: Sumit Gupta @ 2024-03-20 16:52 UTC (permalink / raw)
To: Beata Michalska, Ionela Voinescu
Cc: linux-kernel, linux-arm-kernel, vanshikonda, sudeep.holla, will,
catalin.marinas, vincent.guittot, yang, lihuisong, linux-tegra
In-Reply-To: <ZfI7pQtXgXAG7RBH@arm.com>
Hi Beata,
>> On Tuesday 12 Mar 2024 at 08:34:28 (+0000), Beata Michalska wrote:
>>> Introducing arm64 specific version of arch_freq_get_on_cpu, cashing on
>>> existing implementation for FIE and AMUv1 support: the frequency scale
>>> factor, updated on each sched tick, serves as a base for retrieving
>>> the frequency for a given CPU, representing an average frequency
>>> reported between the ticks - thus its accuracy is limited.
>>>
>>> The changes have been rather lightly (due to some limitations) tested on
>>> an FVP model.
>>>
>>> Relevant discussions:
>>> [1] https://lore.kernel.org/all/20240229162520.970986-1-vanshikonda@os.amperecomputing.com/
>>> [2] https://lore.kernel.org/all/7eozim2xnepacnnkzxlbx34hib4otycnbn4dqymfziqou5lw5u@5xzpv3t7sxo3/
>>> [3] https://lore.kernel.org/all/20231212072617.14756-1-lihuisong@huawei.com/
>>> [4] https://lore.kernel.org/lkml/ZIHpd6unkOtYVEqP@e120325.cambridge.arm.com/T/#m4e74cb5a0aaa353c60fedc6cfb95ab7a6e381e3c
>>>
>>> v3:
>>> - dropping changes to cpufreq_verify_current_freq
>>> - pulling in changes from Ionela initializing capacity_freq_ref to 0
>>> (thanks for that!) and applying suggestions made by her during last review:
>>> - switching to arch_scale_freq_capacity and arch_scale_freq_ref when
>>> reversing freq scale factor computation
>>> - swapping shift with multiplication
>>> - adding time limit for considering last scale update as valid
>>> - updating frequency scale factor upon entering idle
>>>
>>> v2:
>>> - Splitting the patches
>>> - Adding comment for full dyntick mode
>>> - Plugging arch_freq_get_on_cpu into cpufreq_verify_current_freq instead
>>> of in show_cpuinfo_cur_freq to allow the framework to stay more in sync
>>> with potential freq changes
>>>
>>> Beata Michalska (2):
>>> arm64: Provide an AMU-based version of arch_freq_get_on_cpu
>>> arm64: Update AMU-based frequency scale factor on entering idle
>>>
>>> Ionela Voinescu (1):
>>> arch_topology: init capacity_freq_ref to 0
>>>
>>
>> Should there have been a patch that adds a call to
>> arch_freq_get_on_cpu() from show_cpuinfo_cur_freq() as well?
>>
>> My understanding from this [1] thread and others referenced there is
>> that was something we wanted.
>>
> Right, so I must have missunderstood that, as the way I did read it was that
> it is acceptable to keep things as they are wrt cpufreq sysfs entries.
>
> ---
> BR
> Beata
>> [1] https://lore.kernel.org/lkml/2cfbc633-1e94-d741-2337-e1b0cf48b81b@nvidia.com/
>>
>> Thanks,
>> Ionela.
>>
Yes, the change to show_cpuinfo_cur_freq from [1] is needed.
[1]
https://lore.kernel.org/lkml/20230606155754.245998-1-beata.michalska@arm.com/
Thank you,
Sumit Gupta
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: display: samsung,exynos5-dp: convert to DT Schema
From: Conor Dooley @ 2024-03-20 17:04 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Inki Dae, Seung-Woo Kim, Kyungmin Park, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Daniel Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Alim Akhtar,
dri-devel, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel
In-Reply-To: <20240313182855.14140-1-krzysztof.kozlowski@linaro.org>
[-- Attachment #1.1: Type: text/plain, Size: 370 bytes --]
On Wed, Mar 13, 2024 at 07:28:55PM +0100, Krzysztof Kozlowski wrote:
> + clock-names:
> + items:
> + - const: dp
> + phy-names:
> + items:
> + - const: dp
The items lists here are redundant when you only have a single item, no?
Isnt it just
phy-names:
const: dp
?
Otherwise,
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Thanks,
Conor.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] virtio_ring: Fix the stale index in available ring
From: Keir Fraser @ 2024-03-20 17:15 UTC (permalink / raw)
To: Gavin Shan
Cc: Michael S. Tsirkin, Will Deacon, virtualization, linux-kernel,
jasowang, xuanzhuo, yihyu, shan.gavin, linux-arm-kernel,
Catalin Marinas, mochs
In-Reply-To: <3a6c8b23-af9c-47a7-8c22-8e0a78154bd3@redhat.com>
On Wed, Mar 20, 2024 at 03:24:16PM +1000, Gavin Shan wrote:
>
> Before this patch was posted, I had debugging code to record last 16 transactions
> to the available and used queue from guest and host side. It did reveal the wrong
> head was fetched from the available queue.
>
> [ 11.785745] ================ virtqueue_get_buf_ctx_split ================
> [ 11.786238] virtio_net virtio0: output.0:id 74 is not a head!
> [ 11.786655] head to be released: 036 077
> [ 11.786952]
> [ 11.786952] avail_idx:
> [ 11.787234] 000 63985 <--
> [ 11.787237] 001 63986
> [ 11.787444] 002 63987
> [ 11.787632] 003 63988
> [ 11.787821] 004 63989
> [ 11.788006] 005 63990
> [ 11.788194] 006 63991
> [ 11.788381] 007 63992
> [ 11.788567] 008 63993
> [ 11.788772] 009 63994
> [ 11.788957] 010 63995
> [ 11.789141] 011 63996
> [ 11.789327] 012 63997
> [ 11.789515] 013 63998
> [ 11.789701] 014 63999
> [ 11.789886] 015 64000
Does the error always occur at such a round idx value?
Here, 64000 == 0xFA00. Maybe coincidence but it's improbable enough to be interesting.
This debug code seems rather useful!
-- Keir
> [ 11.790068]
> [ 11.790068] avail_head:
> [ 11.790529] 000 075 <--
> [ 11.790718] 001 036
> [ 11.790890] 002 077
> [ 11.791061] 003 129
> [ 11.791231] 004 072
> [ 11.791400] 005 130
> [ 11.791574] 006 015
> [ 11.791748] 007 074
> [ 11.791918] 008 130
> [ 11.792094] 009 130
> [ 11.792263] 010 074
> [ 11.792437] 011 015
> [ 11.792617] 012 072
> [ 11.792788] 013 129
> [ 11.792961] 014 077 // The last two heads from guest to host: 077, 036
> [ 11.793134] 015 036
>
> [root@nvidia-grace-hopper-05 qemu.main]# cat /proc/vhost
>
> avail_idx
> 000 63998
> 001 64000
> 002 63954 <---
> 003 63955
> 004 63956
> 005 63974
> 006 63981
> 007 63984
> 008 63986
> 009 63987
> 010 63988
> 011 63989
> 012 63992
> 013 63993
> 014 63995
> 015 63997
>
> avail_head
> 000 074
> 001 015
> 002 072
> 003 129
> 004 074 // The last two heads seen by vhost is: 074, 036
> 005 036
> 006 075 <---
> 007 036
> 008 077
> 009 129
> 010 072
> 011 130
> 012 015
> 013 074
> 014 130
> 015 130
>
> used_idx
> 000 64000
> 001 63882 <---
> 002 63889
> 003 63891
> 004 63898
> 005 63936
> 006 63942
> 007 63946
> 008 63949
> 009 63953
> 010 63957
> 011 63981
> 012 63990
> 013 63992
> 014 63993
> 015 63999
>
> used_head
> 000 072
> 001 129
> 002 074 // The last two heads published to guest is: 074, 036
> 003 036
> 004 075 <---
> 005 036
> 006 077
> 007 129
> 008 072
> 009 130
> 010 015
> 011 074
> 012 130
> 013 130
> 014 074
> 015 015
>
> Thanks,
> Gavin
>
>
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v3 0/7] Add virtio_rtc module and related changes
From: David Woodhouse @ 2024-03-20 17:22 UTC (permalink / raw)
To: Peter Hilber, linux-kernel, virtualization, virtio-dev,
linux-arm-kernel, linux-rtc, virtio-comment@lists.oasis-open.org
Cc: Christopher S. Hall, Jason Wang, John Stultz, Michael S. Tsirkin,
netdev, Richard Cochran, Stephen Boyd, Thomas Gleixner, Xuan Zhuo,
Marc Zyngier, Mark Rutland, Daniel Lezcano, Alessandro Zummo,
Alexandre Belloni, Ridoux, Julien, Cornelia Huck, Parav Pandit
In-Reply-To: <61364452-bdf5-4bd8-adb1-a9e6236c9d26@opensynergy.com>
[-- Attachment #1.1: Type: text/plain, Size: 2248 bytes --]
On Tue, 2024-03-19 at 14:47 +0100, Peter Hilber wrote:
> While the virtio-comment list is not available, now also CC'ing Parav,
> which may be interested in this virtio-rtc spec related discussion thread.
>
> On 14.03.24 15:19, David Woodhouse wrote:
> > On 14 March 2024 11:13:37 CET, Peter Hilber <peter.hilber@opensynergy.com> wrote:
> > > > To a certain extent, as long as the virtio-rtc device is designed to expose time precisely and unambiguously, it's less important if the Linux kernel *today* can use that. Although of course we should strive for that. Let's be...well, *unambiguous*, I suppose... that we've changed topics to discuss that though.
> > > >
> > >
> > > As Virtio is extensible (unlike hardware), my approach is to mostly specify
> > > only what also has a PoC user and a use case.
> >
> > If we get memory-mapped (X, Y, Z, ±x, ±y) I'll have a user and a use case on day one. Otherwise, as I said in my first response, I can go do that as a separate device and decide that virtio_rtc doesn't meet our needs (especially for maintaining accuracy over LM).
>
> We plan to add
>
> - leap second indication,
>
> - UTC-to-TAI offset,
>
> - clock smearing indication (including the noon-to-noon linear smearing
> variant which seems to be somewhat popular), and
>
> - clock accuracy indication
>
> to the initial spec and to the PoC implementation.
Sounds good, thanks! I look forward to seeing the new revision. I'm
hoping Julien can give feedback on the clock accuracy parts.
> However, due to resource restrictions, we cannot ourselves add the
> memory-mapped clock to the initial spec.
>
> Everyone is very welcome to contribute the memory-mapped clock to the spec,
> and I think it might then still make it to the initial version.
Makes sense. That is my primary target, so I'm *hoping* we can converge
and get that into your initial spec, otherwise for expediency I'm going
to have to define an ACPI or DT or PCI device of our own and expose the
memory region through that instead.
(Even if I have to do that in the short term to stop the bleeding with
customers' clocks and live migration, I'd still aspire to migrate to a
virtio_rtc version of it in future)
[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5965 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/4] Enable JPEG encoding on rk3588
From: Emmanuel Gil Peyrot @ 2024-03-20 17:37 UTC (permalink / raw)
To: linux-kernel
Cc: Emmanuel Gil Peyrot, Ezequiel Garcia, Philipp Zabel,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Joerg Roedel, Will Deacon,
Robin Murphy, Sebastian Reichel, Cristian Ciocaltea, Dragan Simic,
Shreeya Patel, Chris Morgan, Andy Yan, Nicolas Frattaroli,
linux-media, linux-rockchip, devicetree, linux-arm-kernel, iommu
Only the JPEG encoder is available for now, although there are patches
for the undocumented VP8 encoder floating around[0].
This has been tested on a rock-5b, resulting in four /dev/video*
encoders. The userspace program I’ve been using to test them is
Onix[1], using the jpeg-encoder example, it will pick one of these four
at random (but displays the one it picked):
% ffmpeg -i <input image> -pix_fmt yuvj420p temp.yuv
% jpeg-encoder temp.yuv <width> <height> NV12 <quality> output.jpeg
[0] https://patchwork.kernel.org/project/linux-rockchip/list/?series=789885
[1] https://crates.io/crates/onix
Emmanuel Gil Peyrot (4):
dt-bindings: iommu: rockchip: Fix rk3588 variant
media: dt-binding: media: Document rk3588’s vepu121
arm64: dts: rockchip: Add VEPU121 to rk3588
media: verisilicon: Enable VEPU121 on rk3588
.../bindings/media/rockchip,rk3568-vepu.yaml | 1 +
arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 82 ++++++++++++++++++-
drivers/iommu/rockchip-iommu.c | 3 +
.../media/platform/verisilicon/hantro_drv.c | 1 +
.../media/platform/verisilicon/hantro_hw.h | 1 +
.../platform/verisilicon/rockchip_vpu_hw.c | 13 +++
6 files changed, 100 insertions(+), 1 deletion(-)
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/4] arm64: dts: rockchip: Add VEPU121 to rk3588
From: Emmanuel Gil Peyrot @ 2024-03-20 17:37 UTC (permalink / raw)
To: linux-kernel
Cc: Emmanuel Gil Peyrot, Ezequiel Garcia, Philipp Zabel,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Joerg Roedel, Will Deacon,
Robin Murphy, Sebastian Reichel, Cristian Ciocaltea, Dragan Simic,
Shreeya Patel, Chris Morgan, Andy Yan, Nicolas Frattaroli,
linux-media, linux-rockchip, devicetree, linux-arm-kernel, iommu
In-Reply-To: <20240320173736.2720778-1-linkmauve@linkmauve.fr>
The TRM (version 1.0 page 385) lists five VEPU121 cores, but only four
interrupts are listed (on page 24), so I’ve only enabled four of them
for now.
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
---
arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 80 +++++++++++++++++++++++
1 file changed, 80 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
index 2a23b4dc36e4..fe77b56ac9a0 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
@@ -2488,6 +2488,86 @@ gpio4: gpio@fec50000 {
};
};
+ jpeg_enc0: video-codec@fdba0000 {
+ compatible = "rockchip,rk3588-vepu121";
+ reg = <0x0 0xfdba0000 0x0 0x800>;
+ interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru ACLK_JPEG_ENCODER0>, <&cru HCLK_JPEG_ENCODER0>;
+ clock-names = "aclk", "hclk";
+ iommus = <&jpeg_enc0_mmu>;
+ power-domains = <&power RK3588_PD_VDPU>;
+ };
+
+ jpeg_enc0_mmu: iommu@fdba0800 {
+ compatible = "rockchip,rk3588-iommu";
+ reg = <0x0 0xfdba0800 0x0 0x40>;
+ interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru ACLK_JPEG_ENCODER0>, <&cru HCLK_JPEG_ENCODER0>;
+ clock-names = "aclk", "iface";
+ power-domains = <&power RK3588_PD_VDPU>;
+ #iommu-cells = <0>;
+ };
+
+ jpeg_enc1: video-codec@fdba4000 {
+ compatible = "rockchip,rk3588-vepu121";
+ reg = <0x0 0xfdba4000 0x0 0x800>;
+ interrupts = <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru ACLK_JPEG_ENCODER1>, <&cru HCLK_JPEG_ENCODER1>;
+ clock-names = "aclk", "hclk";
+ iommus = <&jpeg_enc1_mmu>;
+ power-domains = <&power RK3588_PD_VDPU>;
+ };
+
+ jpeg_enc1_mmu: iommu@fdba4800 {
+ compatible = "rockchip,rk3588-iommu";
+ reg = <0x0 0xfdba4800 0x0 0x40>;
+ interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru ACLK_JPEG_ENCODER1>, <&cru HCLK_JPEG_ENCODER1>;
+ clock-names = "aclk", "iface";
+ power-domains = <&power RK3588_PD_VDPU>;
+ #iommu-cells = <0>;
+ };
+
+ jpeg_enc2: video-codec@fdba8000 {
+ compatible = "rockchip,rk3588-vepu121";
+ reg = <0x0 0xfdba8000 0x0 0x800>;
+ interrupts = <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru ACLK_JPEG_ENCODER2>, <&cru HCLK_JPEG_ENCODER2>;
+ clock-names = "aclk", "hclk";
+ iommus = <&jpeg_enc2_mmu>;
+ power-domains = <&power RK3588_PD_VDPU>;
+ };
+
+ jpeg_enc2_mmu: iommu@fdba8800 {
+ compatible = "rockchip,rk3588-iommu";
+ reg = <0x0 0xfdba8800 0x0 0x40>;
+ interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru ACLK_JPEG_ENCODER2>, <&cru HCLK_JPEG_ENCODER2>;
+ clock-names = "aclk", "iface";
+ power-domains = <&power RK3588_PD_VDPU>;
+ #iommu-cells = <0>;
+ };
+
+ jpeg_enc3: video-codec@fdbac000 {
+ compatible = "rockchip,rk3588-vepu121";
+ reg = <0x0 0xfdbac000 0x0 0x800>;
+ interrupts = <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru ACLK_JPEG_ENCODER3>, <&cru HCLK_JPEG_ENCODER3>;
+ clock-names = "aclk", "hclk";
+ iommus = <&jpeg_enc3_mmu>;
+ power-domains = <&power RK3588_PD_VDPU>;
+ };
+
+ jpeg_enc3_mmu: iommu@fdbac800 {
+ compatible = "rockchip,rk3588-iommu";
+ reg = <0x0 0xfdbac800 0x0 0x40>;
+ interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru ACLK_JPEG_ENCODER3>, <&cru HCLK_JPEG_ENCODER3>;
+ clock-names = "aclk", "iface";
+ power-domains = <&power RK3588_PD_VDPU>;
+ #iommu-cells = <0>;
+ };
+
av1d: video-codec@fdc70000 {
compatible = "rockchip,rk3588-av1-vpu";
reg = <0x0 0xfdc70000 0x0 0x800>;
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/4] media: dt-binding: media: Document rk3588’s vepu121
From: Emmanuel Gil Peyrot @ 2024-03-20 17:37 UTC (permalink / raw)
To: linux-kernel
Cc: Emmanuel Gil Peyrot, Ezequiel Garcia, Philipp Zabel,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Joerg Roedel, Will Deacon,
Robin Murphy, Sebastian Reichel, Cristian Ciocaltea, Dragan Simic,
Shreeya Patel, Chris Morgan, Andy Yan, Nicolas Frattaroli,
linux-media, linux-rockchip, devicetree, linux-arm-kernel, iommu
In-Reply-To: <20240320173736.2720778-1-linkmauve@linkmauve.fr>
This encoder-only device is present four times on this SoC, and should
support everything the rk3568 vepu supports (so JPEG, H.264 and VP8
encoding).
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
---
.../devicetree/bindings/media/rockchip,rk3568-vepu.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml b/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml
index 9d90d8d0565a..947ad699cc5e 100644
--- a/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml
+++ b/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml
@@ -17,6 +17,7 @@ properties:
compatible:
enum:
- rockchip,rk3568-vepu
+ - rockchip,rk3588-vepu121
reg:
maxItems: 1
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/4] dt-bindings: iommu: rockchip: Fix rk3588 variant
From: Emmanuel Gil Peyrot @ 2024-03-20 17:37 UTC (permalink / raw)
To: linux-kernel
Cc: Emmanuel Gil Peyrot, Ezequiel Garcia, Philipp Zabel,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Joerg Roedel, Will Deacon,
Robin Murphy, Sebastian Reichel, Cristian Ciocaltea, Dragan Simic,
Shreeya Patel, Chris Morgan, Andy Yan, Nicolas Frattaroli,
linux-media, linux-rockchip, devicetree, linux-arm-kernel, iommu
In-Reply-To: <20240320173736.2720778-1-linkmauve@linkmauve.fr>
The documentation got added in f8aa519976b38e67aae02d2db3e2998513305e80,
but it hasn’t been added to the driver so it was unused.
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
---
arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 2 +-
drivers/iommu/rockchip-iommu.c | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
index 87b83c87bd55..2a23b4dc36e4 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
@@ -704,7 +704,7 @@ vp3: port@3 {
};
vop_mmu: iommu@fdd97e00 {
- compatible = "rockchip,rk3588-iommu", "rockchip,rk3568-iommu";
+ compatible = "rockchip,rk3588-iommu";
reg = <0x0 0xfdd97e00 0x0 0x100>, <0x0 0xfdd97f00 0x0 0x100>;
interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH 0>;
clocks = <&cru ACLK_VOP>, <&cru HCLK_VOP>;
diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index da79d9f4cf63..da0e93c139d1 100644
--- a/drivers/iommu/rockchip-iommu.c
+++ b/drivers/iommu/rockchip-iommu.c
@@ -1361,6 +1361,9 @@ static const struct of_device_id rk_iommu_dt_ids[] = {
{ .compatible = "rockchip,rk3568-iommu",
.data = &iommu_data_ops_v2,
},
+ { .compatible = "rockchip,rk3588-iommu",
+ .data = &iommu_data_ops_v2,
+ },
{ /* sentinel */ }
};
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 4/4] media: verisilicon: Enable VEPU121 on rk3588
From: Emmanuel Gil Peyrot @ 2024-03-20 17:37 UTC (permalink / raw)
To: linux-kernel
Cc: Emmanuel Gil Peyrot, Ezequiel Garcia, Philipp Zabel,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Joerg Roedel, Will Deacon,
Robin Murphy, Sebastian Reichel, Cristian Ciocaltea, Dragan Simic,
Shreeya Patel, Chris Morgan, Andy Yan, Nicolas Frattaroli,
linux-media, linux-rockchip, devicetree, linux-arm-kernel, iommu
In-Reply-To: <20240320173736.2720778-1-linkmauve@linkmauve.fr>
Only the JPEG encoder is available for now, although there are patches
for the undocumented VP8 encoder floating around[0].
This has been tested on a rock-5b, resulting in four /dev/video*
encoders. The userspace program I’ve been using to test them is
Onix[1], using the jpeg-encoder example, it will pick one of these four
at random (but displays the one it picked):
% ffmpeg -i <input image> -pix_fmt yuvj420p temp.yuv
% jpeg-encoder temp.yuv <width> <height> NV12 <quality> output.jpeg
[0] https://patchwork.kernel.org/project/linux-rockchip/list/?series=789885
[1] https://crates.io/crates/onix
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
---
drivers/media/platform/verisilicon/hantro_drv.c | 1 +
drivers/media/platform/verisilicon/hantro_hw.h | 1 +
.../media/platform/verisilicon/rockchip_vpu_hw.c | 13 +++++++++++++
3 files changed, 15 insertions(+)
diff --git a/drivers/media/platform/verisilicon/hantro_drv.c b/drivers/media/platform/verisilicon/hantro_drv.c
index 34b123dafd89..8d38dbb5a1eb 100644
--- a/drivers/media/platform/verisilicon/hantro_drv.c
+++ b/drivers/media/platform/verisilicon/hantro_drv.c
@@ -722,6 +722,7 @@ static const struct of_device_id of_hantro_match[] = {
{ .compatible = "rockchip,rk3399-vpu", .data = &rk3399_vpu_variant, },
{ .compatible = "rockchip,rk3568-vepu", .data = &rk3568_vepu_variant, },
{ .compatible = "rockchip,rk3568-vpu", .data = &rk3568_vpu_variant, },
+ { .compatible = "rockchip,rk3588-vepu121", .data = &rk3588_vepu121_variant, },
{ .compatible = "rockchip,rk3588-av1-vpu", .data = &rk3588_vpu981_variant, },
#endif
#ifdef CONFIG_VIDEO_HANTRO_IMX8M
diff --git a/drivers/media/platform/verisilicon/hantro_hw.h b/drivers/media/platform/verisilicon/hantro_hw.h
index 7737320cc8cc..340101200be5 100644
--- a/drivers/media/platform/verisilicon/hantro_hw.h
+++ b/drivers/media/platform/verisilicon/hantro_hw.h
@@ -405,6 +405,7 @@ extern const struct hantro_variant rk3328_vpu_variant;
extern const struct hantro_variant rk3399_vpu_variant;
extern const struct hantro_variant rk3568_vepu_variant;
extern const struct hantro_variant rk3568_vpu_variant;
+extern const struct hantro_variant rk3588_vepu121_variant;
extern const struct hantro_variant rk3588_vpu981_variant;
extern const struct hantro_variant sama5d4_vdec_variant;
extern const struct hantro_variant sunxi_vpu_variant;
diff --git a/drivers/media/platform/verisilicon/rockchip_vpu_hw.c b/drivers/media/platform/verisilicon/rockchip_vpu_hw.c
index f97527670783..aad59b8b1fb5 100644
--- a/drivers/media/platform/verisilicon/rockchip_vpu_hw.c
+++ b/drivers/media/platform/verisilicon/rockchip_vpu_hw.c
@@ -797,6 +797,19 @@ const struct hantro_variant px30_vpu_variant = {
.num_clocks = ARRAY_SIZE(rockchip_vpu_clk_names)
};
+const struct hantro_variant rk3588_vepu121_variant = {
+ .enc_offset = 0x0,
+ .enc_fmts = rockchip_vpu_enc_fmts,
+ .num_enc_fmts = ARRAY_SIZE(rockchip_vpu_enc_fmts),
+ .codec = HANTRO_JPEG_ENCODER,
+ .codec_ops = rk3568_vepu_codec_ops,
+ .irqs = rk3568_vepu_irqs,
+ .num_irqs = ARRAY_SIZE(rk3568_vepu_irqs),
+ .init = rockchip_vpu_hw_init,
+ .clk_names = rockchip_vpu_clk_names,
+ .num_clocks = ARRAY_SIZE(rockchip_vpu_clk_names)
+};
+
const struct hantro_variant rk3588_vpu981_variant = {
.dec_offset = 0x0,
.dec_fmts = rockchip_vpu981_dec_fmts,
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 09/13] mm/powerpc: Redefine pXd_huge() with pXd_leaf()
From: Christophe Leroy @ 2024-03-20 17:40 UTC (permalink / raw)
To: Peter Xu, Aneesh Kumar K.V
Cc: Jason Gunthorpe, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-arm-kernel@lists.infradead.org, Matthew Wilcox,
linuxppc-dev@lists.ozlabs.org, Andrew Morton, x86@kernel.org,
Mike Rapoport, Muchun Song, sparclinux@vger.kernel.org,
Michael Ellerman, Nicholas Piggin, Naveen N. Rao
In-Reply-To: <ZfsKIResY4YcxkxK@x1n>
Le 20/03/2024 à 17:09, Peter Xu a écrit :
> On Wed, Mar 20, 2024 at 06:16:43AM +0000, Christophe Leroy wrote:
>> At the first place that was to get a close fit between hardware
>> pagetable topology and linux pagetable topology. But obviously we
>> already stepped back for 512k pages, so let's go one more step aside and
>> do similar with 8M pages.
>>
>> I'll give it a try and see how it goes.
>
> So you're talking about 8M only for 8xx, am I right?
Yes I am.
>
> There seem to be other PowerPC systems use hugepd. Is it possible that we
> convert all hugepd into cont_pte form?
Indeed.
Seems like we have hugepd for book3s/64 and for nohash.
For book3s I don't know, may Aneesh can answer.
For nohash I think it should be possible because TLB misses are handled
by software. Even the e6500 which has a hardware tablewalk falls back on
software walk when it is a hugepage IIUC.
Christophe
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 16/27] iommu/arm-smmu-v3: Keep track of valid CD entries in the cd_table
From: Jason Gunthorpe @ 2024-03-20 18:21 UTC (permalink / raw)
To: Michael Shavit
Cc: iommu, Joerg Roedel, linux-arm-kernel, Robin Murphy, Will Deacon,
Eric Auger, Jean-Philippe Brucker, Moritz Fischer, Nicolin Chen,
patches, Shameerali Kolothum Thodi
In-Reply-To: <CAKHBV26uFZW_=fEyLTZpx_aVVBS-t8mRn30hx+JvyLRtpw0g4g@mail.gmail.com>
On Tue, Mar 19, 2024 at 09:55:17PM +0800, Michael Shavit wrote:
> On Tue, Mar 5, 2024 at 7:44 AM Jason Gunthorpe <jgg@nvidia.com> wrote:
> >
> > We no longer need a master->sva_enable to control what attaches are
> > allowed.
> >
> > Instead keep track inside the cd_table how many valid CD entries exist,
> > and if the RID has a valid entry.
> >
> > Replace all the attach focused master->sva_enabled tests with a check if
> > the CD has valid entries (or not). If there are any valid entries then the
> > CD table must be currently programmed to the STE.
> >
> > Tested-by: Nicolin Chen <nicolinc@nvidia.com>
> > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> > ---
> > .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 5 +---
> > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 26 ++++++++++---------
> > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 10 +++++++
> > 3 files changed, 25 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> > index ab9de8e36c45f5..82b9c4d4061c3d 100644
> > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> > @@ -433,9 +433,6 @@ static int __arm_smmu_sva_bind(struct device *dev, struct mm_struct *mm,
> > if (smmu_domain->stage != ARM_SMMU_DOMAIN_S1)
> > return -ENODEV;
> >
> I assume this doesn't matter because of subsequent patches, but the
> check above could also be removed since used_sid precisely means that
> the attached domain is an ARM_SMMU_DOMAIN_S1 domain.
Right, but lets move the delete here for clarity.
The same comment applies to some later patches too that do:
if (!arm_smmu_is_s1_domain(iommu_get_domain_for_dev(master->dev)) ||
!master->cd_table.used_sid)
return -ENODEV;
> > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> > index 98dc5885c48655..7e1f6af4ce4e79 100644
> > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> > @@ -602,11 +602,21 @@ struct arm_smmu_ctx_desc_cfg {
> > dma_addr_t cdtab_dma;
> > struct arm_smmu_l1_ctx_desc *l1_desc;
> > unsigned int num_l1_ents;
> > + unsigned int used_ssids;
> > + bool used_sid;
>
> This probably deserves a comment. There's plenty of places where the
> "rid" domain is handled as the CD with ssid 0; but we don't count it
> as a used_ssid here.
As a page table? I didn't think so, the only way to get a CD page table
installed is through arm_smmu_write_cd_entry() which will capture
this..
Non paging domains don't get captured here, they are translating the
RID but they are not using the CD table.
> I also don't find the meaning of used_sid obvious, especially if I
> didn't have the context from the commit description.
Hum, okay, so looking over all of this again I think we can
simplify. At the end there was only one place using used_sid and it
can instead be calling arm_smmu_ssids_in_use() directly:
@@ -2987,11 +2986,13 @@ static void arm_smmu_remove_dev_pasid(struct device *dev, ioasid_t pasid)
* When the last user of the CD table goes away downgrade the STE back
* to a non-cd_table one.
*/
- if (last_ssid && !master->cd_table.used_sid) {
+ if (!arm_smmu_ssids_in_use(&master->cd_table)) {
struct iommu_domain *sid_domain =
iommu_get_domain_for_dev(master->dev);
- sid_domain->ops->attach_dev(sid_domain, master->dev);
+ if (domain->type == IOMMU_DOMAIN_IDENTITY ||
+ domain->type == IOMMU_DOMAIN_BLOCKED)
+ sid_domain->ops->attach_dev(sid_domain, dev);
}
Then we can get rid of used_sid and just have used_ssids count the
!0 ssids directly.
I reorganized a bunch of things in the in between patches so we go
more directly to this final outcome.
Thanks,
Jason
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 12/27] iommu/arm-smmu-v3: Start building a generic PASID layer
From: Jason Gunthorpe @ 2024-03-20 18:32 UTC (permalink / raw)
To: Michael Shavit
Cc: iommu, Joerg Roedel, linux-arm-kernel, Robin Murphy, Will Deacon,
Eric Auger, Jean-Philippe Brucker, Moritz Fischer, Nicolin Chen,
patches, Shameerali Kolothum Thodi
In-Reply-To: <CAKHBV24XKLf2Pw-CXQng0+ppMHp=3qr8vOWT=S=gTiY35kCF5Q@mail.gmail.com>
On Wed, Mar 20, 2024 at 12:11:36AM +0800, Michael Shavit wrote:
> > @@ -448,19 +446,10 @@ static int __arm_smmu_sva_bind(struct device *dev, ioasid_t pasid,
> > goto err_free_bond;
> > }
> >
> > - cdptr = arm_smmu_get_cd_ptr(master, mm_get_enqcmd_pasid(mm));
> > - if (!cdptr) {
> > - ret = -ENOMEM;
> > - goto err_put_notifier;
> > - }
> > - arm_smmu_make_sva_cd(&target, master, mm, bond->smmu_mn->cd->asid);
> > - arm_smmu_write_cd_entry(master, pasid, cdptr, &target);
> > -
> > + arm_smmu_make_sva_cd(target, master, mm, bond->smmu_mn->cd->asid);
> This can probably already move out to arm_smmu_sva_set_dev_pasid in
> this commit. Removing the arm_smmu_get_cd_ptr pre-alloc might also be
> possible if we're careful with failure of arm_smmu_set_pasid.
> This is eventually addressed in "iommu/arm-smmu-v3: Put the SVA mmu
> notifier in the smmu_domain", but that patch is already big enough as
> it is and the change fits nicely here.
Since all this bond related code is going to be deleted I didn't want
to mess with it too much, but sure it looks like this:
static int arm_smmu_sva_set_dev_pasid(struct iommu_domain *domain,
struct device *dev, ioasid_t id)
{
struct arm_smmu_master *master = dev_iommu_priv_get(dev);
struct mm_struct *mm = domain->mm;
struct arm_smmu_bond *bond;
struct arm_smmu_cd target;
int ret;
if (mm_get_enqcmd_pasid(mm) != id)
return -EINVAL;
mutex_lock(&sva_lock);
bond = __arm_smmu_sva_bind(dev, mm);
if (IS_ERR(bond)) {
mutex_unlock(&sva_lock);
return PTR_ERR(bond);
}
arm_smmu_make_sva_cd(&target, master, mm, bond->smmu_mn->cd->asid);
ret = arm_smmu_set_pasid(master, to_smmu_domain(domain), id, &target);
if (ret) {
list_del(&bond->list);
arm_smmu_mmu_notifier_put(bond->smmu_mn);
kfree(bond);
mutex_unlock(&sva_lock);
return ret;
}
mutex_unlock(&sva_lock);
return 0;
}
Which is much closer to the final arrangment in later patches.
Jason
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 21/27] iommu/arm-smmu-v3: Put the SVA mmu notifier in the smmu_domain
From: Jason Gunthorpe @ 2024-03-20 18:35 UTC (permalink / raw)
To: Michael Shavit
Cc: iommu, Joerg Roedel, linux-arm-kernel, Robin Murphy, Will Deacon,
Eric Auger, Jean-Philippe Brucker, Moritz Fischer, Nicolin Chen,
patches, Shameerali Kolothum Thodi
In-Reply-To: <CAKHBV24+c4ZB2ehRgp+hRX4LcQtTr8ZeU==+==gwbT+-J28Zmw@mail.gmail.com>
On Wed, Mar 20, 2024 at 12:23:02AM +0800, Michael Shavit wrote:
> > static void arm_smmu_sva_domain_free(struct iommu_domain *domain)
> > {
> > - kfree(to_smmu_domain(domain));
> > + struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
> > +
> > + /*
> > + * Ensure the ASID is empty in the iommu cache before allowing reuse.
> > + */
> > + arm_smmu_tlb_inv_asid(smmu_domain->smmu, smmu_domain->cd.asid);
> > +
> > + /*
> > + * Notice that the arm_smmu_mm_arch_invalidate_secondary_tlbs op can
> > + * still be called/running at this point. We allow the ASID to be
> > + * reused, and if there is a race then it just suffers harmless
> > + * unnecessary invalidation.
> > + */
> > + xa_erase(&arm_smmu_asid_xa, smmu_domain->cd.asid);
> > +
> > + /*
> > + * Actual free is defered to the SRCU callback
> > + * arm_smmu_mmu_notifier_free()
> > + */
> > + mmu_notifier_put(&smmu_domain->mmu_notifier);
> > }
>
> I'm far from familiar with mmu_notifier and how the sva layers manage
> its reference count....but is calling mmu_notifier_unregister instead
> of mmu_notifier_put possible here?
Possible yes, but it is not good for performance..
The reason I created the mmnut_notifier_put() scheme is to avoid the
synchronize_srcu() penalty in places like this. We don't want to wait
around for a grace period just to destroy an iommu_domain.
So the put scheme piggybacks on the call_srcu that the does the rest
of the cleanup and we get the last bits of freeing done asynchronously.
All of this is because the notifier ops callers are protected by srcu
locks for performance and we can't guarentee no ops are running
without a grace period.
Jason
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v3 5/5] mm: support large folios swapin as a whole
From: Barry Song @ 2024-03-20 18:38 UTC (permalink / raw)
To: Huang, Ying
Cc: Ryan Roberts, Matthew Wilcox, akpm, linux-mm, chengming.zhou,
chrisl, david, hannes, kasong, linux-arm-kernel, linux-kernel,
mhocko, nphamcs, shy828301, steven.price, surenb, wangkefeng.wang,
xiang, yosryahmed, yuzhao, Chuanhua Han, Barry Song
In-Reply-To: <87msqts9u1.fsf@yhuang6-desk2.ccr.corp.intel.com>
On Wed, Mar 20, 2024 at 7:22 PM Huang, Ying <ying.huang@intel.com> wrote:
>
> Barry Song <21cnbao@gmail.com> writes:
>
> > On Wed, Mar 20, 2024 at 3:20 PM Huang, Ying <ying.huang@intel.com> wrote:
> >>
> >> Ryan Roberts <ryan.roberts@arm.com> writes:
> >>
> >> > On 19/03/2024 09:20, Huang, Ying wrote:
> >> >> Ryan Roberts <ryan.roberts@arm.com> writes:
> >> >>
> >> >>>>>> I agree phones are not the only platform. But Rome wasn't built in a
> >> >>>>>> day. I can only get
> >> >>>>>> started on a hardware which I can easily reach and have enough hardware/test
> >> >>>>>> resources on it. So we may take the first step which can be applied on
> >> >>>>>> a real product
> >> >>>>>> and improve its performance, and step by step, we broaden it and make it
> >> >>>>>> widely useful to various areas in which I can't reach :-)
> >> >>>>>
> >> >>>>> We must guarantee the normal swap path runs correctly and has no
> >> >>>>> performance regression when developing SWP_SYNCHRONOUS_IO optimization.
> >> >>>>> So we have to put some effort on the normal path test anyway.
> >> >>>>>
> >> >>>>>> so probably we can have a sysfs "enable" entry with default "n" or
> >> >>>>>> have a maximum
> >> >>>>>> swap-in order as Ryan's suggestion [1] at the beginning,
> >> >>>>>>
> >> >>>>>> "
> >> >>>>>> So in the common case, swap-in will pull in the same size of folio as was
> >> >>>>>> swapped-out. Is that definitely the right policy for all folio sizes? Certainly
> >> >>>>>> it makes sense for "small" large folios (e.g. up to 64K IMHO). But I'm not sure
> >> >>>>>> it makes sense for 2M THP; As the size increases the chances of actually needing
> >> >>>>>> all of the folio reduces so chances are we are wasting IO. There are similar
> >> >>>>>> arguments for CoW, where we currently copy 1 page per fault - it probably makes
> >> >>>>>> sense to copy the whole folio up to a certain size.
> >> >>>>>> "
> >> >>>
> >> >>> I thought about this a bit more. No clear conclusions, but hoped this might help
> >> >>> the discussion around policy:
> >> >>>
> >> >>> The decision about the size of the THP is made at first fault, with some help
> >> >>> from user space and in future we might make decisions to split based on
> >> >>> munmap/mremap/etc hints. In an ideal world, the fact that we have had to swap
> >> >>> the THP out at some point in its lifetime should not impact on its size. It's
> >> >>> just being moved around in the system and the reason for our original decision
> >> >>> should still hold.
> >> >>>
> >> >>> So from that PoV, it would be good to swap-in to the same size that was
> >> >>> swapped-out.
> >> >>
> >> >> Sorry, I don't agree with this. It's better to swap-in and swap-out in
> >> >> smallest size if the page is only accessed seldom to avoid to waste
> >> >> memory.
> >> >
> >> > If we want to optimize only for memory consumption, I'm sure there are many
> >> > things we would do differently. We need to find a balance between memory and
> >> > performance. The benefits of folios are well documented and the kernel is
> >> > heading in the direction of managing memory in variable-sized blocks. So I don't
> >> > think it's as simple as saying we should always swap-in the smallest possible
> >> > amount of memory.
> >>
> >> It's conditional, that is,
> >>
> >> "if the page is only accessed seldom"
> >>
> >> Then, the page swapped-in will be swapped-out soon and adjacent pages in
> >> the same large folio will not be accessed during this period.
> >>
> >> So, I suggest to create an algorithm to decide swap-in order based on
> >> swap-readahead information automatically. It can detect the situation
> >> above via reduced swap readahead window size. And, if the page is
> >> accessed for quite long time, and the adjacent pages in the same large
> >> folio are accessed too, swap-readahead window will increase and large
> >> swap-in order will be used.
> >
> > The original size of do_anonymous_page() should be honored, considering it
> > embodies a decision influenced by not only sysfs settings and per-vma
> > HUGEPAGE hints but also architectural characteristics, for example
> > CONT-PTE.
> >
> > The model you're proposing may offer memory-saving benefits or reduce I/O,
> > but it entirely disassociates the size of the swap in from the size prior to the
> > swap out.
>
> Readahead isn't the only factor to determine folio order. For example,
> we must respect "never" policy to allocate order-0 folio always.
> There's no requirements to use swap-out order in swap-in too. Memory
> allocation has different performance character of storage reading.
Still quite unclear.
If users have only enabled 64KiB (4-ORDER) large folios in sysfs, and the
readahead algorithm requires 16KiB, what should be set as the large folio size?
Setting it to 16KiB doesn't align with users' requirements, while
setting it to 64KiB
would be wasteful according to your criteria.
>
> > Moreover, there's no guarantee that the large folio generated by
> > the readahead window is contiguous in the swap and can be added to the
> > swap cache, as we are currently dealing with folio->swap instead of
> > subpage->swap.
>
> Yes. We can optimize only when all conditions are satisfied. Just like
> other optimization.
>
> > Incidentally, do_anonymous_page() serves as the initial location for allocating
> > large folios. Given that memory conservation is a significant consideration in
> > do_swap_page(), wouldn't it be even more crucial in do_anonymous_page()?
>
> Yes. We should consider that too. IIUC, that is why mTHP support is
> off by default for now. After we find a way to solve the memory usage
> issue. We may make default "on".
It's challenging to establish a universal solution because various systems
exhibit diverse hardware characteristics, and VMAs may require different
alignments. The current sysfs and per-vma hints allow users the opportunity
o customize settings according to their specific requirements.
>
> > A large folio, by its nature, represents a high-quality resource that has the
> > potential to leverage hardware characteristics for the benefit of the
> > entire system.
>
> But not at the cost of memory wastage.
>
> > Conversely, I don't believe that a randomly determined size dictated by the
> > readahead window possesses the same advantageous qualities.
>
> There's a readahead algorithm which is not pure random.
>
> > SWP_SYNCHRONOUS_IO devices are not reliant on readahead whatsoever,
> > their needs should also be respected.
>
> I understand that there are special requirements for SWP_SYNCHRONOUS_IO
> devices. I just suggest to work on general code before specific
> optimization.
I disagree with your definition of "special" and "general". According
to your logic,
non-SWP_SYNCHRONOUS_IO devices could also be classified as "special".
Furthermore, the number of systems running SWP_SYNCHRONOUS_IO is
significantly greater than those running non-SWP_SYNCHRONOUS_IO,
contradicting your assertion.
SWP_SYNCHRONOUS_IO devices have a minor chance of being involved
in readahead. However, in OPPO's code, which hasn't been sent in the
LKML yet, we use the exact same size as do_anonymous_page for readahead.
Without a clear description of how you want the new readahead
algorithm to balance memory waste and users' hints from sysfs and
per-vma flags, it appears to be an ambiguous area to address.
Please provide a clear description of how you would like the new readahead
algorithm to function. I believe this clarity will facilitate others
in attempting to
implement it.
>
> >> > You also said we should swap *out* in smallest size possible. Have I
> >> > misunderstood you? I thought the case for swapping-out a whole folio without
> >> > splitting was well established and non-controversial?
> >>
> >> That is conditional too.
> >>
> >> >>
> >> >>> But we only kind-of keep that information around, via the swap
> >> >>> entry contiguity and alignment. With that scheme it is possible that multiple
> >> >>> virtually adjacent but not physically contiguous folios get swapped-out to
> >> >>> adjacent swap slot ranges and then they would be swapped-in to a single, larger
> >> >>> folio. This is not ideal, and I think it would be valuable to try to maintain
> >> >>> the original folio size information with the swap slot. One way to do this would
> >> >>> be to store the original order for which the cluster was allocated in the
> >> >>> cluster. Then we at least know that a given swap slot is either for a folio of
> >> >>> that order or an order-0 folio (due to cluster exhaustion/scanning). Can we
> >> >>> steal a bit from swap_map to determine which case it is? Or are there better
> >> >>> approaches?
> >> >>
> >> >> [snip]
>
> --
> Best Regards,
> Huang, Ying
Thanks
Barry
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 1/5] dt-bindings: misc: Add mikrobus-connector
From: Andrew Lunn @ 2024-03-20 18:44 UTC (permalink / raw)
To: Ayush Singh
Cc: Vaishnav Achath, Michael Walle, Krzysztof Kozlowski, open list,
jkridner, robertcnelson, lorforlinux, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Nishanth Menon,
Vignesh Raghavendra, Tero Kristo, Derek Kiernan, Dragan Cvetic,
Arnd Bergmann, Greg Kroah-Hartman, Mark Brown, Johan Hovold,
Alex Elder,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/TEXAS INSTRUMENTS K3 ARCHITECTURE,
open list:SPI SUBSYSTEM, moderated list:GREYBUS SUBSYSTEM,
Vaishnav M A
In-Reply-To: <c3223f90-6e7c-4fdc-905a-770c474445e2@gmail.com>
On Wed, Mar 20, 2024 at 10:09:05PM +0530, Ayush Singh wrote:
> On 3/20/24 01:02, Andrew Lunn wrote:
>
> > > Yes, after discussion with Vaishnav and trying to brainstorm some way to do
> > > the same thing with dt overlays, it seems that trying to use dt overlays
> > > will mean need to have completely separate implementation of mikroBUS for
> > > local ports and mikroBUS over greybus.
> > Could you explain why please?
> >
> > Are greybus I2C bus masters different from physical I2C bus masters?
> > Are greybus SPI bus masters different from physical SPI bus masters?
>
> Well, they are virtual, so they are not declared in the device tree. I have
> linked the greybus i2c implementation. It basically allocates an i2c_adpater
> and then adds it using `i2c_add_adapter` method. This adapter can then be
> passed to say mikroBUS driver where it can be used as a normal i2c_adapter,
> and we can register the device to it.
Being virtual does not really stop it being added to the DT.
I'm making this all up, but i assume it will look something like this:
greybus@42 {
compatible = "acme,greybus";
reg = <0x42 0x100>;
This would represent the greybus host controller.
module@0 {
reg = <0>;
This would represent a module discovered on the bus. I assume there is
some sort of addressing? The greybus core code dynamically creates the
node in DT to describe the modules it has discovered. This is not too
different to USB. You can already describe USB devices in DT, but the
assumption is you know they exists, e.g. because they are hard wired,
not hot-plugable. The USB core will associate the USB device with the
node in DT. But actually creating a node in DT is not too big a jump.
interface@0 {
compatible = "greybus,i2c";
reg = <0>;
}
interface@1 {
compatible = "greybus,spi";
reg = <1>;
}
interface@10 {
compatible = "greybus,gpio";
reg = <10>;
}
It can then enumerate the interfaces on the module, and create the I2C
node, SPI bus node, the gpio controller etc. Again, the greybus core
can add nodes to DT to described the discovered hardware, and
associate them to the linux devices which are created.
That gives you what you need to load a DT overlay to make use of these
devices. That overlay would contain one of your virtual mikroBUS
controllers. This virtual controller is basically a phandle-proxy. The
virtual mikroBUS controllers is a consumer of phandles to an I2C bus,
an SPI bus, GPIO bus which makes up the pins routed to the mikroBUS
connector. The virtual mikroBUS controllers is also a provider of an
I2C bus, an SPI bus, GPIO controller. The mikroBUS device consumes
these I2C bus, SPI bus etc. The virtual mikroBUS controllers makes it
simpler for the device to find the resources it needs, since they are
all in one place. For a physical mikroBUS you have a DT node with
phandles to the physical devices. For greybus you create a virtual
device with phandles to the virtual devices added to the DT bus.
You then have everything you need to describe the mikroBUS
devices. For very simple devices you convert the manifest to a DT
overlay and load it. For complex devices you directly use a DT
overlay.
I also don't see any need to do the manifest to DT overlay conversion
on the fly. You have a database of manifests. They could be converted
to DT and then added to the linux-firmware repo, for example. If
device with an unknown manifest is found, it should be possible to
read the manifest in userspace via its eeprom in /sys/class/. An tool
could create DT blob and add it to /lib/firmware to get it working
locally, and provide suggestions how to contribute it to the linux
firmware project?
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [arch/arm/mach-mvebu] Question about kzalloc NULL check in i2c_quirk
From: zzjas98 @ 2024-03-20 18:48 UTC (permalink / raw)
To: Andrew Lunn, gregory.clement, sebastian.hesselbarth, linux,
linux-arm-kernel, chenyuan0y
In-Reply-To: <fdfb3e09-5ec7-4455-ab7a-158906736c3a@lunn.ch>
On 3/20/24 7:27 AM, Andrew Lunn <andrew@lunn.ch> wrote:
> On Tue, Mar 19, 2024 at 10:03:22PM -0500, Zijie Zhao wrote:
> > Dear ARM/Marvell maintainers,
> >
> > We came across an unusual usage of kzalloc in
> > arch/arm/mach-mvebu/board-v7.c, function i2c_quirk:
> >
> > https://elixir.bootlin.com/linux/v6.8/source/arch/arm/mach-mvebu/board-v7.c#L127
> > ```
> > static void __init i2c_quirk(void)
> > {
> > struct device_node *np;
> > u32 dev, rev;
> >
> > /*
> > * Only revisons more recent than A0 support the offload
> > * mechanism. We can exit only if we are sure that we can
> > * get the SoC revision and it is more recent than A0.
> > */
> > if (mvebu_get_soc_id(&dev, &rev) == 0 && rev > MV78XX0_A0_REV)
> > return;
> >
> > for_each_compatible_node(np, NULL, "marvell,mv78230-i2c") {
> > struct property *new_compat;
> >
> > new_compat = kzalloc(sizeof(*new_compat), GFP_KERNEL);
> >
> > new_compat->name = kstrdup("compatible", GFP_KERNEL);
> > new_compat->length = sizeof("marvell,mv78230-a0-i2c");
> > new_compat->value = kstrdup("marvell,mv78230-a0-i2c",
> > GFP_KERNEL);
> >
> > of_update_property(np, new_compat);
> > }
> > }
> > ```
> >
> > Should the new_compat be checked against NULL in case kzalloc fails, to
> > avoid NULL dereference later in the code?
> >
> > Please kindly let us know if we missed any key information and this is
> > actually intended. We appreciate your information and time! Thanks!
>
> What context is this code run in? What would need to happen for the
> allocation to fail? And what happens next if it does fail, both in
> this function and the system in general?
>
> Andrew
>
Hi Andrew,
Thanks for checking!
We encountered this kzalloc while doing a static analysis for the kernel code.
kzalloc would return NULL in case of out-of-memory and would make the next field access new_compat->name segfault.
However, we are not sure if i2c_quirk, used in an init_machine hook, has any special assumption, so would appreciate your knowledge to decide whether an NULL check is needed.
Best,
Zijie
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [arch/arm/mach-mvebu] Question about kzalloc NULL check in i2c_quirk
From: Andrew Lunn @ 2024-03-20 19:03 UTC (permalink / raw)
To: zzjas98
Cc: gregory.clement, sebastian.hesselbarth, linux, linux-arm-kernel,
chenyuan0y
In-Reply-To: <2baa9e59-fe81-4c92-b6ca-a86233c5e06d@gmail.com>
> > What context is this code run in? What would need to happen for the
> > allocation to fail? And what happens next if it does fail, both in
> > this function and the system in general?
> >
> > Andrew
> >
>
> Hi Andrew,
>
> Thanks for checking!
>
> We encountered this kzalloc while doing a static analysis for the kernel code.
>
> kzalloc would return NULL in case of out-of-memory and would make the next field access new_compat->name segfault.
>
> However, we are not sure if i2c_quirk, used in an init_machine hook, has any special assumption, so would appreciate your knowledge to decide whether an NULL check is needed.
Please configure your email client to wrap lines at around 70
characters.
O.K, let me help you answer your questions.
When is init_machine called?
What would need to happen for the allocation to fail?
Say it does fall, and you avoid a NULL pointer dereference here. What
happens next to the system in general.
These are not hard questions to answer, you just need to think about
them a little.
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox