linux-kernel - Re: drm/msm/mdp5: undefined CONFIG_MSM_BUS

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: <CAF6AEGsQ=dkREnU5bA=EJCF6o3h+DwcSUd1V2Hvu-rat5-+ypw@mail.gmail.com>
Date:	Thu, 9 Apr 2015 10:50:58 -0400
From:	Rob Clark <robdclark@...il.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	Valentin Rothberg <valentinrothberg@...il.com>,
	Hai Li <hali@...eaurora.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	David Airlie <airlied@...ux.ie>,
	Paul Bolle <pebolle@...cali.nl>, rupran@...server.de,
	stefan.hengelein@....de
Subject: Re: drm/msm/mdp5: undefined CONFIG_MSM_BUS_SCALING

On Thu, Apr 9, 2015 at 10:20 AM, Greg KH <gregkh@...uxfoundation.org> wrote:
> On Thu, Apr 09, 2015 at 09:49:58AM -0400, Rob Clark wrote:
>> On Thu, Apr 9, 2015 at 7:22 AM, Valentin Rothberg
>> <valentinrothberg@...il.com> wrote:
>> > Hi Hai,
>> >
>> > your commit d5af49c92a8a ("drm/msm/mdp5: Enable DSI connector in msm drm
>> > driver") in today's Linux next tree adds an #ifdef with CONFIG_MSM_BUS_SCALING
>> > as condition.  MSM_BUS_SCALING is not defined in Kconfig, so the code in this
>> > #ifdef block won't be compiled at its current state.
>> >
>> > I saw some references on this Kconfig option in other files; is there a
>> > reason for the absence of MSM_BUS_SCALING?
>>
>> right now, it is something that only exists in downstream kernels (for
>> example, android device kernels).. but in those kernels it is
>> mandatory to use, as by default the memory/bus is downclocked and the
>> display would underflow if we did not request sufficient bandwidth.
>>
>> It only exists right now in the upstream kernel to simplify
>> backporting to various device kernels
>
> That's crazy.  You are asking upstream to maintain code in order to just
> make out of tree crap easier to maintain, which you don't have any plan
> to ever upstream?  That causes havoc on static analysis tools and
> prevents anyone from ever being able to even change the code for new api
> changes and test build it.

Hey, don't blame me for the downstream kernels.  But at various points
in time I've had to backport drm/msm to various device kernels in
order to work on the userspace/mesa end of things.  (And, well, there
are other crazy folks out there who want to get open source graphics
drivers working on various phones/tablets.)  It was a choice to make
my life easier.  You know, because reverse engineering a gpu is a walk
in the park..

BR,
-R


> If this was in a subsystem that I maintain, I'd delete it tomorrow.  But
> in the end, it's up to David to decide if he wants to waste the cycles
> or not.
>
> Ick ick ick.
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/