Hi,
On 03/13/2014 01:57 PM, Austin Boyle wrote:
Hi Gerlando,
[...]
In my opinion, we're breaking something here (call it userspace API or
otherwise). My suggestion would then be to make it an optional feature to be
explicitly enabled on the device tree, like Heicho did for CFI flashes:
ht
Hi Gerlando,
On Mon, 10 Mar 2014, Gerlando Falauto wrote:
What do you mean exactly by "it is optional"?
I agree with you that an explicit ioctl(MEMLOCK) is order for locking to take
place. However, this seems to be the default action for the u-boot
environment userspace tools. They will issue
Hi Austin, Brian,
thank you for taking care of this.
On 03/08/2014 04:03 PM, Austin Boyle wrote:
[...]
I don't think there is an issue with some bootloaders not supporting
this feature, it is already optional.
What do you mean exactly by "it is optional"?
I agree with you that an explicit io
Hi all,
I am very sorry I missed this discussion, that was my previous work email
address. Thanks for finding me Brian!
> On Thu, Feb 27, 2014 at 03:34:06PM +0100, Gerlando Falauto wrote:
> > >2) While I believe this might work on m25p32, m25p64 and m25p128 (i.e.
> > >flashes with 64 blocks or
Different email for Austin?
On Wed, Mar 05, 2014 at 12:10:08AM -0800, Brian Norris wrote:
> + Marek, Angus
>
> On Thu, Feb 27, 2014 at 03:34:06PM +0100, Gerlando Falauto wrote:
> > Hi,
> >
> > it's me again.
> > In my opinion (and experience) this introduces a pretty serious bug
> > (not to ment
+ Marek, Angus
On Thu, Feb 27, 2014 at 03:34:06PM +0100, Gerlando Falauto wrote:
> Hi,
>
> it's me again.
> In my opinion (and experience) this introduces a pretty serious bug
> (not to mention the compatibility issues), yet I haven't heard a
> single word or found a patch applied about it in thr
Hi,
it's me again.
In my opinion (and experience) this introduces a pretty serious bug (not
to mention the compatibility issues), yet I haven't heard a single word
or found a patch applied about it in three months.
Am I the only one having this issue? Or maybe I'm just "seeing things"?
Thank
Hi,
On 01/04/2013 01:02 AM, Austin Boyle wrote:
This patch adds generic support for flash protection on STmicro chips.
On chips with less than 3 protection bits, the unused bits are don't cares
and so can be written anyway.
I have two remarks:
1) I believe this introduces incompatibilities wi
On Fri, 2013-01-04 at 13:02 +1300, Austin Boyle wrote:
> This patch adds generic support for flash protection on STmicro chips.
> On chips with less than 3 protection bits, the unused bits are don't cares
> and so can be written anyway. The lock function will only change the
> protection bits if it
9 matches
Mail list logo
