Yes, that patch indeed solves my problem as well. Why isn't it in a
generic (all platforms) patch area?
On Sat, May 8, 2010 at 5:13 AM, wrote:
> could you try if
> trunk/target/linux/etrax/patches-2.6.32/200-samsung_flash.patch
> fixes your issues ?
>
> Quoting "Michael J. Evans" :
>
>> At LEAS
Florian, I'm very much not a fan of the Makefile level solution you've used.
Is that behavior required to work regardless of multi-threading
linkers/make processes? I can see situations where it could work for
some builders all the time, some builders none of the time, and some
builders intermitt
Looking at the printk my patch adds, the vendor EC (IIRC Samsung)
should match, but I see '0' and '0' for major and minor chars.
I think it's likely that the more specific patch will work, I'm
looking in to setting up a test now.
On Sat, May 8, 2010 at 10:26 AM, Mic
I can try it later tonight; ah I see, that's for a different arch.
This is a generic issue why wasn't that shared with all arches?
It may fix //my// issue, but shouldn't the right thing to do be to
accept any chip claiming basic CFI compliance?
On Sat, May 8, 2010 at 5:13 AM, wrote:
> could you
I have two patches I'd like to submit, currently they are in this format:
target/linux/ar7/patches-2.6.32/970-clock-init-race-fix.patch
target/linux/ar7/patches-2.6.32/980-CFI-generic-tolerance.patch
I might be able to use the exim4 server I setup for caff (OpenPGP
signature automation) to send a
