From: Jean Delvare <jdelvare@suse.de>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
"Jon Medhurst (Tixy)" <tixy@linaro.org>,
Greg KH <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] firmware: arm_scpi: Add hardware dependencies
Date: Fri, 27 Jan 2017 09:53:17 +0100 [thread overview]
Message-ID: <20170127095317.2f780a7f@endymion> (raw)
In-Reply-To: <4521295e-e1f9-f4b0-358f-6a1e421ebc8a@arm.com>
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@vger.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@kernel.org, so that ARM SoC team can pick this up directly.
I can't see this address in MAINTAINERS.
--
Jean Delvare
SUSE L3 Support
next prev parent reply other threads:[~2017-01-27 9:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-25 13:32 [PATCH] firmware: arm_scpi: Add hardware dependencies Jean Delvare
2017-01-25 13:38 ` Sudeep Holla
2017-01-25 13:50 ` Jean Delvare
2017-01-25 13:56 ` Sudeep Holla
2017-01-25 14:14 ` Jean Delvare
2017-01-25 14:20 ` Sudeep Holla
2017-01-25 15:04 ` Jean Delvare
2017-01-25 15:15 ` Sudeep Holla
2017-01-27 8:53 ` Jean Delvare [this message]
2017-01-27 9:00 ` Greg KH
2017-01-27 14:22 ` Sudeep Holla
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170127095317.2f780a7f@endymion \
--to=jdelvare@suse.de \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sudeep.holla@arm.com \
--cc=tixy@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox