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: <1j1pw20xxf.fsf@starbuckisacylon.baylibre.com>
Date: Thu, 13 Feb 2025 14:35:56 +0100
From: Jerome Brunet <jbrunet@...libre.com>
To: "Arnd Bergmann" <arnd@...db.de>
Cc: "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,  "Dave Ertman"
 <david.m.ertman@...el.com>,  "Ira Weiny" <ira.weiny@...el.com>,  "Rafael J
 . Wysocki" <rafael@...nel.org>,  "Stephen Boyd" <sboyd@...nel.org>,
  "Danilo Krummrich" <dakr@...nel.org>,  "Conor.Dooley"
 <conor.dooley@...rochip.com>,  "Daire McNamara"
 <daire.mcnamara@...rochip.com>,  "Philipp Zabel" <p.zabel@...gutronix.de>,
  "Doug Anderson" <dianders@...omium.org>,  "Andrzej Hajda"
 <andrzej.hajda@...el.com>,  "Neil Armstrong" <neil.armstrong@...aro.org>,
  "Robert Foss" <rfoss@...nel.org>,  "laurent.pinchart"
 <Laurent.pinchart@...asonboard.com>,  "Jonas Karlman" <jonas@...boo.se>,
  "Jernej Skrabec" <jernej.skrabec@...il.com>,  "Maarten Lankhorst"
 <maarten.lankhorst@...ux.intel.com>,  "Maxime Ripard"
 <mripard@...nel.org>,  "Thomas Zimmermann" <tzimmermann@...e.de>,  "Dave
 Airlie" <airlied@...il.com>,  "Simona Vetter" <simona@...ll.ch>,  "Hans de
 Goede" <hdegoede@...hat.com>,  Ilpo Järvinen
 <ilpo.jarvinen@...ux.intel.com>,  "Bryan O'Donoghue"
 <bryan.odonoghue@...aro.org>,  "Vladimir Kondratiev"
 <vladimir.kondratiev@...ileye.com>,  "Gregory Clement"
 <gregory.clement@...tlin.com>,  Théo Lebrun
 <theo.lebrun@...tlin.com>,
  "Michael Turquette" <mturquette@...libre.com>,  "Abel Vesa"
 <abelvesa@...nel.org>,  "Peng Fan" <peng.fan@....com>,  "Shawn Guo"
 <shawnguo@...nel.org>,  "Sascha Hauer" <s.hauer@...gutronix.de>,
  "Pengutronix Kernel Team" <kernel@...gutronix.de>,  "Fabio Estevam"
 <festevam@...il.com>,  "Kevin Hilman" <khilman@...libre.com>,  "Martin
 Blumenstingl" <martin.blumenstingl@...glemail.com>,
  linux-kernel@...r.kernel.org,  linux-riscv@...ts.infradead.org,
  dri-devel@...ts.freedesktop.org,  platform-driver-x86@...r.kernel.org,
  linux-mips@...r.kernel.org,  linux-clk@...r.kernel.org,
  imx@...ts.linux.dev,  linux-arm-kernel@...ts.infradead.org,
  linux-amlogic@...ts.infradead.org
Subject: Re: [PATCH v3 7/7] clk: amlogic: axg-audio: use the auxiliary reset
 driver - take 2

On Thu 13 Feb 2025 at 13:26, "Arnd Bergmann" <arnd@...db.de> wrote:

> On Tue, Feb 11, 2025, at 18:28, Jerome Brunet wrote:
>>
>>  I also think this is more readeable and maintainable than a bunch of
>>  'default CONFIG_FOO if CONFIG_FOO' for CONFIG_RESET_MESON_AUX. This approach
>>  also would have several pitfall, such as picking the value of the first config
>>  set or the config of RESET_MESON_AUX staying to 'n' if CONFIG_FOO is turned on
>>  with menuconfig.
>
> I still think you should just drop the 'imply' line, all it does it
> force reviewers to double-check that you didn't make a mistake
> here, so it's a waste of time.

Arnd, you've made you preference clear and this note has been added
specifically for this reason, and transparency. 

I've exposed a technical reason for my choice. Going with the 'default'
approach makes things more difficult in the long run for those
maintaining this platform, me included.

The trouble of having to coordinate changes in 2 different subsystems to
have an appropriate configuration and the pitfalls of using 'default'
outweigh the extra review trouble of using 'imply' ... especially when
the pitfall mentioned in documentation is explicitly addressed in the
description.

If there something wrong with 'imply' existing and being used, maybe the
Documentation should be updated to reflect this, or the support be
removed entirely.

ATM, it exists and it makes things a lot easier for me to support and
maintain this device.

This all started with a maintainer request to move some resets away
from clock. More requests have been added along the way, making things
more generic. I'm more than happy to have contributed my effort and
time on this and I don't think anybody's time has been wasted so far.

>
>     Arnd

-- 
Jerome

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ