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:   Tue, 14 Feb 2017 13:03:27 -0800
From:   John Stultz <john.stultz@...aro.org>
To:     John Stultz <john.stultz@...aro.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Chen Feng <puck.chen@...ilicon.com>,
        Xinwei Kong <kong.kongxinwei@...ilicon.com>,
        Xinliang Liu <z.liuxinliang@...ilicon.com>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Rongrong Zou <zourongrong@...il.com>,
        Daniel Vetter <daniel.vetter@...el.com>
Cc:     Daniel Vetter <daniel@...ll.ch>
Subject: Re: [RFC][PATCH 1/2] drm/probe-helper: Add mode_valid check to drm_crtc_helper_funcs

On Tue, Feb 14, 2017 at 12:22 PM, Daniel Vetter <daniel@...ll.ch> wrote:
> On Tue, Feb 14, 2017 at 11:45:54AM -0800, John Stultz wrote:
>>
>> Not following here. What do you mean by "put it into drivers"?  Where?
>
> In your driver callback for ->mode_valid, call into a shared function to
> validate CRTC limits. Which you also call from the crtc's ->mode_fixup
> function.

So bascially have the adv7511 driver's mode_valid() have a special
callback to the kirin (and freedreno, and whatever other) drm driver
to check the modes? Or I guess the drm driver that uses that bridge
should register something w/ the adv7511 code?

Part of my confusion here is that the main issue is that its not just
one driver I'm dealing with, and they're all really just tied together
via device tree, so I'm not sure how to special case it in just one of
the drivers.

> In short my complain here is that this is only a partial solution of the
> larger problem, specific for your driver. That kind of code is better put
> into drivers, until we have a clear understanding to type up something
> complete in the helpers. Shared code is imo overrated :-)

Yea, apologies for my not seeing the larger problem at first (its
still a bit hazy, really), part of this submission is just trying to
get something to throw darts at and figure out the right thing.

But I'll try to figure out another approach here.

thanks
-john

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ