On 02/06/17 10:23, Brian Norris wrote:
> On Thu, Jun 01, 2017 at 09:30:07PM +0000, Chris Packham wrote:
>> On 02/06/17 06:43, Brian Norris wrote:
>>> On Wed, May 17, 2017 at 05:29:11PM +0200, Boris Brezillon wrote:
>>>> Can we fix allocate_partition() to properly handle the
>>>> master->erasesize == 0 case instead of doing that?
>>>
>>> Is everything actually ready for the eraseblock size to be 0?
>>
>> That was my initial motivation for faking it.
>
> Understood. I think it's probably better to avoid hacking drivers like
> you were about to, but I was also curious if anyone had thought through
> the implications of *not* forcing a non-zero size.
>
>>> That would
>>> seem surprising to many applications, I would think. Can you, for
>>> instance, even use UBI on such a device?
>>
>> I've tried ext2 and I believe Andrew has tried minix fs. We're talking
>> SRAM so UBI/UBIFS doesn't really provide much benefit for this use-case.
>
> Right. But that's not necessarily true for all NO_ERASE devices, so we'd
> probably want to think about that before allowing it.
Do we need a flag to indicate SRAM-like properties? I assume there is a
difference between NO_ERASE on ROM devices where there is just no way of
erasing the data. For {S,F,M}RAM there is no block erase operation but
you can overwrite data to destroy it (which is actually my use-case with
this SPI SRAM). I was tempted to set erase_size = 1 at one point which
in my mind was technically accurate but would probably upset the mtd
layer just as much as 0.
On Thu, Jun 01, 2017 at 11:08:08PM +0000, Chris Packham wrote:
> Do we need a flag to indicate SRAM-like properties? I assume there is a
> difference between NO_ERASE on ROM devices where there is just no way of
> erasing the data. For {S,F,M}RAM there is no block erase operation but
I think we already have that:
#define MTD_CAP_ROM 0
#define MTD_CAP_RAM (MTD_WRITEABLE | MTD_BIT_WRITEABLE | MTD_NO_ERASE)
The key signifier for ROM would be !MTD_WRITEABLE.
> you can overwrite data to destroy it (which is actually my use-case with
> this SPI SRAM). I was tempted to set erase_size = 1 at one point which
> in my mind was technically accurate but would probably upset the mtd
> layer just as much as 0.
I'm not sure what erasesize should be here. I suppose 0, but really, I
think the MTD_NO_ERASE flag is the clearer indication that erase is not
needed, and that one should ignore the erasesize.
Brian