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]
Date:   Mon, 16 Jan 2023 16:29:29 +0100
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Tony Lindgren <tony@...mide.com>
Cc:     Adam Ford <aford173@...il.com>,
        Andreas Kemnade <andreas@...nade.info>,
        BenoƮt Cousson <bcousson@...libre.com>,
        robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
        linux-omap@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ARM: dts: gta04: fix excess dma channel usage

Hi,

> Am 16.01.2023 um 15:51 schrieb Tony Lindgren <tony@...mide.com>:
> 
> Hi,
> 
> * Adam Ford <aford173@...il.com> [230116 14:16]:
>> Would it make sense to make this default in the omap3.dtsi file and
>> enable them in the individual boards that need it?
> 
> In general disabling the unused devices by default for omaps will break
> the power management. The disabled devices are completely ignored by the
> kernel, and the devices are left to whatever the bootloader state might
> be.

Yes, indeed.

> For SoCs using firmware to manage devices it's a bit different story
> however. The firmware can still idle disabled devices based on a
> late_initcall for example, even if the kernel knows nothing about the
> disabled devices.

But how can we then handle all devices being "okay" by default and
eating up more dma channels than are available?

We can't put all under power management AND dma by default.

Or can dma channel usage be postponed until the device is really used?

BR,
Nikolaus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ