As for today HSDK reset driver implements only
.reset() callback.
In case of driver which implements one of standard
reset controller usage pattern
(call *_deassert() in probe(), call *_assert() in remove())
that leads to inoperability of this reset driver.
Improve HSDK reset driver by calling
On 08/27/18 06:11, Peter Zijlstra wrote:
> On Mon, Aug 27, 2018 at 05:26:53AM -0700, H. Peter Anvin wrote:
>
>> _THIS_IP_, however, is completely ill-defined, other than being an
>> address *somewhere* in the same global function (not even necessarily
>> the same function if the function is
On Mon, Aug 27, 2018 at 05:26:53AM -0700, H. Peter Anvin wrote:
> _THIS_IP_, however, is completely ill-defined, other than being an
> address *somewhere* in the same global function (not even necessarily
> the same function if the function is static!) As my experiment show, in
> many (nearly)
On 08/27/18 00:33, Peter Zijlstra wrote:
>
> What problem are we trying to solve? _THIS_IP_ and _RET_IP_ work fine.
> We're 'good' at dealing with text addresses, we use them for call stacks
> and all sorts. Why does this need changing?
>
_RET_IP_ works fine, with the following two caveats:
1.
[ Trimmed the cc list because my SMTP didn't accept that many
addresses. ]
On Sun, 26 Aug 2018 13:25:14 -0700
Linus Torvalds wrote:
> On Sun, Aug 26, 2018 at 12:32 PM H. Peter Anvin wrote:
> >
> > Here is a full-blown (user space) test program demonstrating the whole
> > technique and how to
On Sun, Aug 26, 2018 at 07:52:59PM -0700, Nick Desaulniers wrote:
> On Sun, Aug 26, 2018 at 1:25 PM Linus Torvalds
> > Instead, maybe we could encourage something like
> >
> > struct kernel_loc { const char *file; const char *fn; int line; };
> >
> > #define __GEN_LOC__(n) \
> > ({