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: <154335513853.88331.9713562640538396853@swboyd.mtv.corp.google.com>
Date:   Tue, 27 Nov 2018 13:45:38 -0800
From:   Stephen Boyd <swboyd@...omium.org>
To:     Lina Iyer <ilina@...eaurora.org>
Cc:     evgreen@...omium.org, marc.zyngier@....com,
        linux-kernel@...r.kernel.org, rplsssn@...eaurora.org,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        thierry.reding@...il.com
Subject: Re: [RFC v3 2/3] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent
 for GPIO

Quoting Lina Iyer (2018-11-27 10:21:23)
> On Tue, Nov 27 2018 at 02:12 -0700, Stephen Boyd wrote:
> >
> >Two reasons. First, simplicity. The TLMM driver just needs to pass the
> >gpio number up to the PDC gpio domain and then that domain can figure
> >out what hwirq it maps to within the PDC hw irq space. I don't see any
> >reason why we have to know the hwirq of PDC within the TLMM driver
> >besides "let's not be different".
> >
> >And second, it makes it easier for us to implement the MPM case in the
> >TLMM driver by letting the TLMM code just ask "should I mask the irq
> >here or not?" by passing that with a wrapper struct around the fwspec
> >and a dedicated domain in the PDC/MPM driver. Keeping less things in the
> >TLMM driver and not driving the decision from DT but from tables in the
> >PDC driver also keeps things simple and reduces DT parsing code/time.
> >
> Couldn't this be simply achieved by matching the compatible flags for
> PDC/MPM bindings for the wakeup-parent in the TLMM driver? 
> 

It could be, but then we would be making TLMM highly aware of the wakeup
parent and have to do compatible string matching in two places, instead
of making TLMM more abstractly aware that it needs to keep things masked
while irq parent deals with the interrupts.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ