linux-kernel - Re: [PATCH] firmware: arm_scpi: Add hardware dependencies

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: <20170127095317.2f780a7f@endymion>
Date:   Fri, 27 Jan 2017 09:53:17 +0100
From:   Jean Delvare <jdelvare@...e.de>
To:     Sudeep Holla <sudeep.holla@....com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        "Jon Medhurst (Tixy)" <tixy@...aro.org>,
        Greg KH <gregkh@...uxfoundation.org>
Subject: Re: [PATCH] firmware: arm_scpi: Add hardware dependencies

Hi Sudeep,

On Wed, 25 Jan 2017 15:15:45 +0000, Sudeep Holla wrote:
> Also different maintainer have different opinion on how to use
> COMPILE_TEST. I don't have any strong opinion on that.

There's not much to discuss or disagree about COMPILE_TEST. It was
introduced for one purpose and should be used for that one purpose:
restrict driver visibility to the relevant platforms without hindering
the build test coverage.

> (...)
> I agree, but generally I have seen suggestions no to add too much
> dependency if it's not required and that's why I wanted to learn the
> details.

I think you are speaking about something different. You don't want to
have dependencies on subsystems or options which your driver doesn't
actually need, of course. But limiting drivers to their intended or
actual architectures or platforms is a different kind of dependencies,
so that rule doesn't apply.

> > (...)
> > As a side note, there's no finger-pointing implied by Fixes: tags. They
> > are only meant to help people backporting patches, so that they know if
> > something they backported is later fixed up. It does not imply anything
> > regarding how serious the problem was.
> 
> Yes, but sometimes it's taken for stable tree

Really? I would expect that only patches tagged with "Cc:
stable@...r.kernel.org", or explicitly sent to that list, are
considered for stable trees. Greg, you don't pick commits for stable
trees just because they have a "Fixes:" tag, do you?

> and I don't think patch is
> really fixing anything in that particular commit. e.g. what if x86 had
> MAILBOX enabled, that patch changes nothing. So definitely not stable
> material.

It's not fixing a build breakage, if that's what you were worried
about. I agree it's not stable material and I did not Cc stable. For
me, Cc: stable@ and Fixes: are not correlated.

> You can drop the fixes tag and add my ack. Please post it to
> arm@...nel.org, so that ARM SoC team can pick this up directly.

I can't see this address in MAINTAINERS.

-- 
Jean Delvare
SUSE L3 Support