[U-Boot] [PATCH 00/16] SF: Migrate to Linux SPI NOR framework

[Jagan Teki]

On Fri, Dec 14, 2018 at 10:12 PM Vignesh R <vigneshr at ti.com> wrote:
>
> >>
> >>     > 2) For BAR support, lets place it as it is and support via
> > spi-nor
> >>
> >     >     Problem is, it not desirable to use BAR as default because its not
> >     >     stateless and does not work with all flash parts. OTOH, it
> >     seems like 4
> >     >     byte addressing (stateless dedicated opcode or with enter/exit
> >     4 byte
> >     >     mode) seems to be standard.
> >     >     Also, Linux doesn't support BAR and haven't seen any request
> >     for BAR
> >     >     support. Why support additional feature and burden of
> >     maintaining when
> >     >     it may not be needed.
> >     >
> >     >     But if you insist, I just have to add BAR support back.
> >     >
> >     >
> >     > But if we do that, could we please have a config option so that I can
> >     > somehow ensure only 4 byte opcoses are used that don't change some
> >     state
> >     > in the chip?
> >     >
> >
> >     I am afraid BAR support would be the default as Jagan suggests not to
> >     change existing behavior. You would have to disable SPI_FLASH_BAR to use
> >     4 Byte addressing opcodes.
> >
> >
> > Honestly, I don't like the idea of making BAR the default. Why can't we
> > go the Linux way and enable BAR (maybe then as default) for boards that
> > need it only?
> >
>
> Jagan, would that be acceptable?

Better way to have some controller flag to check we go with 3-byte or
4-byte addressing if flash > 16MiB. anyway let me give some time, will
come back for the better to way to go this. ofcourse CONFIG would
require if BAR handling code occupy more foot-print, but we have to
enable based some controller indication.