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: <Y8WCrkrOA8w/1KGp@atomide.com>
Date:   Mon, 16 Jan 2023 19:00:30 +0200
From:   Tony Lindgren <tony@...mide.com>
To:     "H. Nikolaus Schaller" <hns@...delico.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

* H. Nikolaus Schaller <hns@...delico.com> [230116 15:29]:
> 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.

See my further clarification based on what Adam commented too, I was
thinking status = "disabled" at the ti-sysc parent level.

> > 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?

1. Set the child device (not the ti-sysc node) with status = "disabled"
   in the board specific file as needed

2. Use /delete-property/ for dma channels in the board specific file
   if the device is in use but does not need dma

3. Or if this is a generic problem, we could disable dma by default for
   some devices

> 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?

Sure.

Regards,

Tony

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ