linux-kernel - Re: [PATCH v8] mtd: spi-nor: Add support for S3AN spi-nor devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 1 Dec 2016 18:52:03 +0100
From:   Ricardo Ribalda Delgado <ricardo.ribalda@...il.com>
To:     Marek Vasut <marek.vasut@...il.com>
Cc:     Cyrille Pitchen <cyrille.pitchen@...el.com>,
        David Woodhouse <dwmw2@...radead.org>,
        Brian Norris <computersforpeace@...il.com>,
        Boris Brezillon <boris.brezillon@...e-electrons.com>,
        Richard Weinberger <richard@....at>,
        "linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v8] mtd: spi-nor: Add support for S3AN spi-nor devices

Hi Marek

Thanks for your review

On Thu, Dec 1, 2016 at 5:05 PM, Marek Vasut <marek.vasut@...il.com> wrote:
>
> On 11/24/2016 05:56 PM, Ricardo Ribalda Delgado wrote:

>> +#define      SPI_S3AN                BIT(10) /*
>> +                                      * Xilinx Spartan 3AN In-System Flash
>> +                                      * (MFR cannot be used for probing
>> +                                      * because it has the same value as
>> +                                      * ATMEL flashes)
>> +                                      */
>
> I have possibly off-topic question. Altera has something very similar --
> EPCS/EPCQ flash which cannot be detected using standard READID .
> Would this patch help with supporting those degenerate flashes too?
>
>>  };
>>

I dont know, but I love the term degenerated flash, please let me use it :)

> >       for (i = 0; i < len; ) {
> >               ssize_t written;
> > +             loff_t addr = to + i;
> > +
> > +             if (hweight32(nor->page_size) == 1) {
> > +                     page_offset = addr & (nor->page_size - 1);
> > +             } else {
> > +                     uint64_t aux = addr;
> >
> > -             page_offset = (to + i) & (nor->page_size - 1);
> > +                     page_offset = do_div(aux, nor->page_size);
> > +             }
>
> Why is this part necessary ?

If page_size is not a power of 2 (264,528),  the & (size-1) operation
for getting the offset  does not work, you need to do a real modulus.

> > +
> > +     /* Flash in Power of 2 mode */
> > +     if (val & XSR_PAGESIZE) {
> > +             nor->page_size = (nor->page_size == 264) ? 256 : 512;
>
> 264 is due to some ECC ?

The flash can be in standard mode or in power of two mode. You need to
check the status register to know if the chip is in one mode or the
other.

The flash is in standard mode from factory, you can change the mode to
power of two, but the data is corrupted and you cannot change  back to
standard mode.

I guess they are using some bits reserved to ECC for data and that way
you can squeeze some bits for user data.

>
> > +             nor->mtd.writebufsize = nor->page_size;
> > +             nor->mtd.size = 8 * nor->page_size * info->n_sectors;
> > +             nor->mtd.erasesize = 8 * nor->page_size;
> > +     } else {
> > +             nor->flags |= SNOR_F_S3AN_ADDR_DEFAULT;
> > +     }
> > +
> > +     return 0;
> > +}
>
> [...]
>
> --
> Best regards,
> Marek Vasut

Thanks Again




-- 
Ricardo Ribalda