linux-kernel - Re: [PATCH 1/2] amba: Add dev_is_amba() function and export it for modules

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] [day] [month] [year] [list]

Message-ID: <CAL_Jsq+FJuwpJe7WW80buqpRCJv4ZHKmjfSPZKnx+4j6NOtoCQ@mail.gmail.com>
Date: Tue, 1 Oct 2024 21:11:28 -0500
From: Rob Herring <robh@...nel.org>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Kunwu Chan <chentao@...inos.cn>, saravanak@...gle.com, linux-kernel@...r.kernel.org, 
	devicetree@...r.kernel.org, 
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Subject: Re: [PATCH 1/2] amba: Add dev_is_amba() function and export it for modules

On Tue, Sep 24, 2024 at 5:44 PM Russell King (Oracle)
<linux@...linux.org.uk> wrote:
>
> On Tue, Sep 24, 2024 at 05:28:57PM -0500, Rob Herring wrote:
> > On Mon, Sep 23, 2024 at 05:42:47PM +0800, Kunwu Chan wrote:
> > > Add dev_is_amba() function to determine
> > > whether the device is a AMBA device.
> > >
> > > Suggested-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
> > > Signed-off-by: Kunwu Chan <chentao@...inos.cn>
> > > ---
> > >  drivers/amba/bus.c       | 6 ++++++
> > >  include/linux/amba/bus.h | 5 +++++
> > >  2 files changed, 11 insertions(+)
> >
> > Russell, Can I get an ack for this to take it with patch #2.
>
> Would be nice to discuss "how shall we merge this cross-subsystem
> patch series" first, hmm?

Sure. IMO and what seems to be typical, since the user is in
drivers/of/ and changing that code is the overall reason for this
series, I think merging it via the DT tree makes the most sense. But
either way is fine with me. I'm happy to either ack it or apply it and
move on to the next thing.

> The reason I didn't take patch 1 originally is because it was submitted
> to me without any users, and the general principle is not to accept
> patches without users. Too many times, I've merged code where there's
> been a "promise" that it will be used, only to have the author go
> silent and users never come along. So now, my rule is... any code that
> adds something must also come with its user.

The user is in drivers/of/ in patch 2 of this series. So no issue there.

Rob