Hmm. I'm used to pull blackfin updates from Bob Liu. I see that he has
signed your gpg key, so this all looks fine, but quite frankly, Id'
much rather be told ahead of time that "oh, expect pulls from another
person".
I do *not* want to end up in some kind of fight over who maintains
what. Bob? Am
On Tue, Apr 23, 2013 at 1:47 PM, Randy Dunlap wrote:
> On 04/23/13 12:35, Geert Uytterhoeven wrote:
>> + error: "vm_iomap_memory" [drivers/video/fb.ko] undefined!: => N/A
>>
>> bfin/BF537-STAMP_defconfig
>
>
> This is a result of the recent iomap changes (I think).
>
> Can Blackfin and others h
On Mon, Jul 23, 2012 at 10:54 PM, Bob Liu wrote:
>
> This is the new pull request about blackfin changes for 3.6-rc1.
> I've rebased my tree to 3.5.
So I pulled it, but next time I'd really like to not see so much
recent rebasing.
So preferably it would be something that has been stable for at l
On Mon, Jul 23, 2012 at 8:54 PM, Bob Liu wrote:
>
> Please pull blackfin changes for 3.6-rc1.
No.
These were clearly rebased today. And on top of random state in the
merge window.
Why would you do that? It's so horribly wrong that there's no way in
hell I'm pulling this mess.
Lin
On Tue, 1 Jun 2010, Mike Frysinger wrote:
>
> to be fair, this patch was written a few kernel revisions ago and
> you're referring to commit merged a few weeks ago ...
Yeah, but it got sent to me today, which is why I reacted. But:
> but i dont think we're talking the same thing. that commit
On Tue, 1 Jun 2010, David Howells wrote:
>
> From: Mike Frysinger
>
> Add support to the NOMMU /proc/pid/maps file to show which mapping is the
> stack
> of the original thread after execve. This is largely based on the MMU code.
Umm? The MMU code that we _reverted_?
It turns out to be tota
On Mon, 22 Jun 2009, John Stoffel wrote:
>
> Linus> Then, just edit the files, and use "git diff". That, along with
> Linus> "git pull" would be the _only_ command you'd ever use - and you
> Linus> now have a nice anoncvs-like environment to get used to git
> Linus> with, without having to actua
On Mon, 22 Jun 2009, John Stoffel wrote:
>
> I just recently submitted a patch, and it took me a while to figure
> out a git flow for stupid, simple patches so that I, a moron, could
> understand it.
Well, your documented flow is pretty advanced, actually. In fact, much
more advanced than what
On Mon, 22 Jun 2009, Mike Frysinger wrote:
>
> should be cleaned up to apply to the master branch
Hmm. Can somebody explain why we even bother to test bprm.cred for NULL
that second time?
Or why we test bprm.file, for that matter? How could it possibly suddenly
become NULL?
Finally, if that
On Mon, 22 Jun 2009, Linus Torvalds wrote:
>
> I applied this patch, but I want to just vent my frustration with it.
Actually, I take that back. I applied it by hand, but then unapplied it,
because the patch also had
res = load_flat_file(&bprm, libs, id, NULL, NULL)
On Mon, 22 Jun 2009, Bernd Schmidt wrote:
>
> This fixes a crash in 2.6.30 with shared flat binaries. prepare_binfmt now
> requires a cred pointer to be set up, which isn't done in binfmt_flat.c.
This has so many bugs in patch submission that I literally almost gave up
despite it being a trivi
Btw, for user space, if you want to do this all right for something like
BF. I think the only _correct_ thing to do (in the sense that the end
result will actually be debuggable) is to essentially give full SMP
coherency in user space.
It's doable, but rather complicated, and I'm not 100% sur
On Fri, 13 Feb 2009, Mathieu Desnoyers wrote:
>
> The whole idea behind _LOAD_SHARED() is that it does not translate in
> any different assembly output than a standard load. So no, it cannot be
> possibly slower. It has no more side-effect than a simple comment in the
> code, and that's its purp
On Fri, 13 Feb 2009, Mathieu Desnoyers wrote:
>
> I created also
>
> _STORE_SHARED()
> _LOAD_SHARED()
>
> which identify the variables which need to have cache flush done before
> (load) or after (store). So we get both speed and identification when
> needed (if we need to do batch updates lin
On Sat, 14 Feb 2009, Nick Piggin wrote:
>
> Interesting. I don't know if you would say it is not cache coherent.
> Does anything in cache coherency definition require timeliness? Only
> causality I think.
Nick, afaik, BF _really_ isn't cache coherent.
It's not about timeliness. It's literally
On Thu, 12 Feb 2009, Paul E. McKenney wrote:
>
> In other words, you are arguing for using ACCESS_ONCE() in the loops,
> but keeping the old ACCESS_ONCE() definition, and declaring BF hardware
> broken?
Well, I _also_ argue that if you have a busy loop, you'd better have a
cpu_relax() in there
On Thu, 12 Feb 2009, Paul E. McKenney wrote:
>
> Actually the best way to do this would be:
>
> while (ACCESS_ONCE(sig_done) < 1)
> continue;
>
> If ACCESS_ONCE() needs to be made architecture-specific to make this
> really work on Blackfin, we should make that change.
I r
17 matches
Mail list logo
