linux-kernel - Re: [PATCH v4 24/24] platform/chrome: cros_ec: Use PM subsystem to manage wakeirq

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: Wed, 3 Jan 2024 16:38:31 -0800
From: Stephen Boyd <swboyd@...omium.org>
To: Mark Hasemeyer <markhas@...omium.org>
Cc: LKML <linux-kernel@...r.kernel.org>, Sudeep Holla <sudeep.holla@....com>, 
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>, Rob Herring <robh@...nel.org>, 
	Andy Shevchenko <andriy.shevchenko@...el.com>, 
	Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>, Konrad Dybcio <konrad.dybcio@...aro.org>, 
	Raul Rangel <rrangel@...omium.org>, Tzung-Bi Shih <tzungbi@...nel.org>, 
	Benson Leung <bleung@...omium.org>, Bhanu Prakash Maiya <bhanumaiya@...omium.org>, 
	Chen-Yu Tsai <wenst@...omium.org>, Guenter Roeck <groeck@...omium.org>, 
	Prashant Malani <pmalani@...omium.org>, Rob Barnes <robbarnes@...gle.com>, 
	chrome-platform@...ts.linux.dev
Subject: Re: [PATCH v4 24/24] platform/chrome: cros_ec: Use PM subsystem to
 manage wakeirq

Quoting Mark Hasemeyer (2024-01-03 14:45:06)
> On Wed, Jan 3, 2024 at 3:25 PM Mark Hasemeyer <markhas@...omium.org> wrote:
> >
> > > The DTS patch would go through the platform maintainer tree and be
> > > pulled into the soc tree and sent up to mainline from there. The
> > > platform/chrome patch would go through chrome platform tree and then to
> > > mainline. The bisection hole will be real.
> >
> > I thought it would all get merged in the next merge window. How are
> > bifurcations like this normally dealt with? Does one wait for the
> > first series of patches to land in mainline before submitting
> > dependent patches? That could take two merge windows.
>
> The DTS dependency problem must be an exception? How are other
> dependency problems resolved? For example, this patch relies on
> changes to 'platform_get_irq()' which is in drivers/base/platform.c,
> which I imagine is in a different subsystem and gets merged into a
> different maintainer's tree.

Cross tree code dependencies like that are usually resolved by having a
maintainer ack the patch and another maintainer take the code parts.

DT bindings are not supposed to be changed in a way that would break
compatibility with existing code, hence the compatible property. It's a
backwards incompatible change to add the wakeup-source property to the
EC binding and make the driver rely on that property to maintain the
previous code behavior. That's why I keep saying that if you want to add
a wakeup-source property and make the driver act the same as before it
must be done with a new compatible string. Because the driver has always
set the device to wakeup, the compatible has implicitly conveyed that
the wakeup-source property is present.