linux-kernel - Re: [PATCH 4/9] soc: sunxi: sram: Fix probe function ordering issues

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4204539.ejJDZkT8p0@jernej-laptop>
Date:   Sun, 14 Aug 2022 12:34:09 +0200
From:   Jernej Škrabec <jernej.skrabec@...il.com>
To:     Chen-Yu Tsai <wens@...e.org>, Samuel Holland <samuel@...lland.org>
Cc:     Samuel Holland <samuel@...lland.org>,
        Arnd Bergmann <arnd@...db.de>,
        Hans de Goede <hdegoede@...hat.com>,
        Icenowy Zheng <icenowy@...c.io>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Maxime Ripard <mripard@...nel.org>,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-sunxi@...ts.linux.dev
Subject: Re: [PATCH 4/9] soc: sunxi: sram: Fix probe function ordering issues

Dne ponedeljek, 01. avgust 2022 ob 05:05:04 CEST je Samuel Holland napisal(a):
> Errors from debugfs are intended to be non-fatal, and should not prevent
> the driver from probing.
> 
> Since debugfs file creation is treated as infallible, move it below the
> parts of the probe function that can fail. This prevents an error
> elsewhere in the probe function from causing the file to leak. Do the
> same for the call to of_platform_populate().
> 
> Finally, checkpatch suggests an octal literal for the file permissions.
> 
> Fixes: 4af34b572a85 ("drivers: soc: sunxi: Introduce SoC driver to map
> SRAMs") Fixes: 5828729bebbb ("soc: sunxi: export a regmap for EMAC clock
> reg on A64") Signed-off-by: Samuel Holland <samuel@...lland.org>

Reviewed-by: Jernej Skrabec <jernej.skrabec@...il.com>

Best regards,
Jernej