04 Apr, 2016

1 commit

  • When map_word gets too large, we use a lot of kernel stack, and for
    MTD_MAP_BANK_WIDTH_32, this means we use more than the recommended
    1024 bytes in a number of functions:

    drivers/mtd/chips/cfi_cmdset_0020.c: In function 'cfi_staa_write_buffers':
    drivers/mtd/chips/cfi_cmdset_0020.c:651:1: warning: the frame size of 1336 bytes is larger than 1024 bytes [-Wframe-larger-than=]
    drivers/mtd/chips/cfi_cmdset_0020.c: In function 'cfi_staa_erase_varsize':
    drivers/mtd/chips/cfi_cmdset_0020.c:972:1: warning: the frame size of 1208 bytes is larger than 1024 bytes [-Wframe-larger-than=]
    drivers/mtd/chips/cfi_cmdset_0001.c: In function 'do_write_buffer':
    drivers/mtd/chips/cfi_cmdset_0001.c:1835:1: warning: the frame size of 1240 bytes is larger than 1024 bytes [-Wframe-larger-than=]

    This can be avoided if all operations on the map word are done
    indirectly and the stack gets reused between the calls. We can
    mostly achieve this by selecting MTD_COMPLEX_MAPPINGS whenever
    MTD_MAP_BANK_WIDTH_32 is set, but for the case that no other
    bank width is enabled, we also need to use a non-constant
    map_bankwidth() to convince the compiler to use less stack.

    Signed-off-by: Arnd Bergmann
    [Brian: this patch mostly achieves its goal by forcing
    MTD_COMPLEX_MAPPINGS (and the accompanying indirection) for 256-bit
    mappings; the rest of the change is mostly a wash, though it helps
    reduce stack size slightly. If we really care about supporting
    256-bit mappings though, we should consider rewriting some of this
    code to avoid keeping and assigning so many 256-bit objects on the
    stack.]
    Signed-off-by: Brian Norris

    Arnd Bergmann
     

01 Dec, 2015

1 commit

  • MTD allows compile-time configuration of the possible CFI geometry
    settings that are allowed by the kernel, but that includes a couple of
    invalid configurations, where no bank width or no interleave setting
    is allowed. These are then caught with a compile-time warning:

    include/linux/mtd/cfi.h:76:2: warning: #warning No CONFIG_MTD_CFI_Ix selected. No NOR chip support can work.
    include/linux/mtd/map.h:145:2: warning: #warning "No CONFIG_MTD_MAP_BANK_WIDTH_xx selected. No NOR chip support can work"

    This is a bit annoying for randconfig tests, and can be avoided if
    we change the Kconfig logic to always select the simplest configuration
    when no other one is enabled.

    Signed-off-by: Arnd Bergmann
    Signed-off-by: Brian Norris

    Arnd Bergmann
     

29 May, 2015

1 commit

  • Commit 4612c715a6ea ("mtd: cfi: deinline large functions") moved some
    code into the cfi_util library without creating a new dependency. So we
    can get build failures like the following, when CONFIG_MTD_JEDECPROBE=y
    and CONFIG_MTD_CFI_UTIL=m.

    drivers/built-in.o: In function `jedec_read_id':
    >> jedec_probe.c:(.text+0x187ed8): undefined reference to `cfi_build_cmd_addr'
    drivers/built-in.o: In function `jedec_read_mfr':
    >> jedec_probe.c:(.text+0x187f4a): undefined reference to `cfi_build_cmd_addr'
    drivers/built-in.o: In function `jedec_reset':
    >> jedec_probe.c:(.text+0x187fe0): undefined reference to `cfi_send_gen_cmd'
    >> jedec_probe.c:(.text+0x188004): undefined reference to `cfi_send_gen_cmd'
    >> jedec_probe.c:(.text+0x18802b): undefined reference to `cfi_send_gen_cmd'
    >> jedec_probe.c:(.text+0x18804e): undefined reference to `cfi_send_gen_cmd'
    drivers/built-in.o: In function `jedec_probe_chip':
    >> jedec_probe.c:(.text+0x188130): undefined reference to `cfi_build_cmd_addr'
    >> jedec_probe.c:(.text+0x18814d): undefined reference to `cfi_build_cmd_addr'
    >> jedec_probe.c:(.text+0x1881dc): undefined reference to `cfi_send_gen_cmd'
    >> jedec_probe.c:(.text+0x188203): undefined reference to `cfi_send_gen_cmd'
    >> jedec_probe.c:(.text+0x18822d): undefined reference to `cfi_send_gen_cmd'
    >> jedec_probe.c:(.text+0x1884c0): undefined reference to `cfi_send_gen_cmd'
    >> jedec_probe.c:(.text+0x1884e7): undefined reference to `cfi_send_gen_cmd'
    drivers/built-in.o:jedec_probe.c:(.text+0x188511): more undefined references to `cfi_send_gen_cmd' follow
    drivers/built-in.o: In function `jedec_probe_chip':
    >> jedec_probe.c:(.text+0x188618): undefined reference to `cfi_build_cmd'

    So let's express the dependency properly.

    Reported-by: kbuild test robot
    Signed-off-by: Brian Norris

    Brian Norris
     

21 May, 2014

1 commit


05 Apr, 2013

1 commit

  • The MTD subsystem has historically tried to be as configurable as possible. The
    side-effect of this is that its configuration menu is rather large, and we are
    gradually shrinking it. For example, we recently merged partitions support with
    the mtdcore.

    This patch does the next step - it merges the mtdchar module to mtdcore. And in
    this case this is not only about eliminating too fine-grained separation and
    simplifying the configuration menu. This is also about eliminating seemingly
    useless kernel module.

    Indeed, mtdchar is a module that allows user-space making use of MTD devices
    via /dev/mtd* character devices. If users do not enable it, they simply cannot
    use MTD devices at all. They cannot read or write the flash contents. Is it a
    sane and useful setup? I believe not. And everyone just enables mtdchar.

    Having mtdchar separate is also a little bit harmful. People sometimes miss the
    fact that they need to enable an additional configuration option to have
    user-space MTD interfaces, and then they wonder why on earth the kernel does
    not allow using the flash? They spend time asking around.

    Thus, let's just get rid of this module and make it part of mtd core.

    Note, mtdchar had additional configuration option to enable OTP interfaces,
    which are present on some flashes. I removed that option as well - it saves a
    really tiny amount space.

    [dwmw2: Strictly speaking, you can mount file systems on MTD devices just
    fine without the mtdchar (or mtdblock) devices; you just can't do
    other manipulations directly on the underlying device. But still I
    agree that it makes sense to make this unconditional. And Yay! we
    get to kill off an instance of checking CONFIG_foo_MODULE, which is
    an abomination that should never happen.]

    Signed-off-by: Artem Bityutskiy
    Signed-off-by: David Woodhouse

    Artem Bityutskiy
     

12 Jan, 2013

1 commit


07 Jul, 2012

1 commit

  • The Kconfig help on "Flash cmd/query data swapping" still mentions
    LART_ENDIAN_BYTE. That option used to be relevant for setting
    CONFIG_MTD_CFI_LART_BIT_SWAP. That option and macro got both removed in
    v2.4.11-pre4. So, although LART endianness sounds intriguing, that part
    of the help text can be removed.

    And, while we're touching this choice, move the help text up one level.
    Currently it's available under the "NO" option, while it's relevant for
    all three options.

    Signed-off-by: Paul Bolle
    Signed-off-by: Artem Bityutskiy
    Signed-off-by: David Woodhouse

    Paul Bolle
     

31 Mar, 2011

1 commit


09 Nov, 2009

1 commit


01 Sep, 2008

1 commit


06 Aug, 2008

1 commit


02 Aug, 2008

1 commit

  • Now that we can tell when we have one of the newer DataFlash chips,
    optionally expose the 128 bytes of OTP memory they provide. Tested
    on at45db642 revision B and D chips.

    Switch mtdchar over to a generic HAVE_MTD_OTP flag instead of adding
    another #ifdef for each type of chip whose driver has OTP support.

    Signed-off-by: David Brownell
    Cc: Bryan Wu
    Cc: Michael Hennerich
    Signed-off-by: Andrew Morton
    Signed-off-by: David Woodhouse

    David Brownell
     

09 May, 2007

1 commit


20 Apr, 2007

1 commit

  • Use menuconfigs instead of menus, so the whole menu can be disabled at once
    instead of going through all options.

    Signed-off-by: Jan Engelhardt
    Signed-off-by: Andrew Morton
    Signed-off-by: David Woodhouse

    Jan Engelhardt
     

04 Oct, 2006

1 commit


09 May, 2006

1 commit


01 Apr, 2006

1 commit

  • Remove the obsolete Kconfig options MTD_CFI_AMDSTD_RETRY
    and MTD_CFI_AMDSTD_RETRY_MAX

    The code that depended on these was removed in early 2004, but
    Kconfig was not updated accordingly.

    Signed-off-by: Anders Larsen
    Signed-off-by: David Woodhouse
    Signed-off-by: Adrian Bunk

    Anders Larsen
     

27 Mar, 2006

1 commit


08 Feb, 2006

1 commit

  • MTD_XIP depends on having working asm/mtd-xip.h; it's not just per-architecture
    (arm-only, as current Kconfig would have it), but actually per-subarch as
    well. Introduced a new symbol (ARCH_MTD_XIP) set by arch Kconfig; MTD_XIP
    depends on it.

    Signed-off-by: Al Viro

    Al Viro
     

17 Jan, 2006

2 commits


07 Nov, 2005

1 commit


12 Jul, 2005

1 commit


29 Jun, 2005

1 commit


23 May, 2005

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds