History log of /linux-6.15/drivers/mtd/maps/Makefile (Results 1 – 25 of 83)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2, v6.15-rc1, v6.14, v6.14-rc7, v6.14-rc6, v6.14-rc5, v6.14-rc4, v6.14-rc3, v6.14-rc2, v6.14-rc1, v6.13, v6.13-rc7, v6.13-rc6, v6.13-rc5, v6.13-rc4, v6.13-rc3, v6.13-rc2, v6.13-rc1, v6.12, v6.12-rc7, v6.12-rc6, v6.12-rc5, v6.12-rc4, v6.12-rc3, v6.12-rc2, v6.12-rc1, v6.11, v6.11-rc7, v6.11-rc6, v6.11-rc5, v6.11-rc4, v6.11-rc3, v6.11-rc2, v6.11-rc1, v6.10, v6.10-rc7, v6.10-rc6, v6.10-rc5, v6.10-rc4, v6.10-rc3, v6.10-rc2, v6.10-rc1, v6.9
# cf4ccd1c 08-May-2024 Andy Shevchenko <[email protected]>

mtd: physmap: Use *-y instead of *-objs in Makefile

*-objs suffix is reserved rather for (user-space) host programs while
usually *-y suffix is used for kernel drivers (although *-objs works
for tha

mtd: physmap: Use *-y instead of *-objs in Makefile

*-objs suffix is reserved rather for (user-space) host programs while
usually *-y suffix is used for kernel drivers (although *-objs works
for that purpose for now).

Let's correct the old usages of *-objs in Makefiles.

Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]

show more ...


Revision tags: v6.9-rc7, v6.9-rc6, v6.9-rc5, v6.9-rc4, v6.9-rc3, v6.9-rc2, v6.9-rc1, v6.8, v6.8-rc7, v6.8-rc6, v6.8-rc5, v6.8-rc4, v6.8-rc3, v6.8-rc2, v6.8-rc1, v6.7, v6.7-rc8, v6.7-rc7, v6.7-rc6, v6.7-rc5
# 77bf0325 08-Dec-2023 Matthew Wilcox (Oracle) <[email protected]>

mtd: Remove support for Carillo Ranch driver

As far as anybody can tell, this product never shipped. If it did,
it shipped in 2007 and nobody has access to one any more. Remove the
mtd NOR driver.

mtd: Remove support for Carillo Ranch driver

As far as anybody can tell, this product never shipped. If it did,
it shipped in 2007 and nobody has access to one any more. Remove the
mtd NOR driver.

Signed-off-by: Matthew Wilcox (Oracle) <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]

show more ...


Revision tags: v6.7-rc4, v6.7-rc3, v6.7-rc2, v6.7-rc1, v6.6, v6.6-rc7, v6.6-rc6, v6.6-rc5, v6.6-rc4, v6.6-rc3, v6.6-rc2, v6.6-rc1, v6.5, v6.5-rc7, v6.5-rc6, v6.5-rc5, v6.5-rc4, v6.5-rc3, v6.5-rc2, v6.5-rc1, v6.4, v6.4-rc7, v6.4-rc6, v6.4-rc5, v6.4-rc4, v6.4-rc3, v6.4-rc2, v6.4-rc1, v6.3, v6.3-rc7, v6.3-rc6, v6.3-rc5, v6.3-rc4, v6.3-rc3, v6.3-rc2, v6.3-rc1, v6.2, v6.2-rc8, v6.2-rc7, v6.2-rc6, v6.2-rc5, v6.2-rc4, v6.2-rc3, v6.2-rc2, v6.2-rc1, v6.1, v6.1-rc8, v6.1-rc7, v6.1-rc6, v6.1-rc5, v6.1-rc4, v6.1-rc3, v6.1-rc2, v6.1-rc1, v6.0, v6.0-rc7, v6.0-rc6, v6.0-rc5, v6.0-rc4, v6.0-rc3, v6.0-rc2, v6.0-rc1, v5.19, v5.19-rc8, v5.19-rc7, v5.19-rc6, v5.19-rc5, v5.19-rc4, v5.19-rc3, v5.19-rc2, v5.19-rc1, v5.18, v5.18-rc7, v5.18-rc6, v5.18-rc5, v5.18-rc4, v5.18-rc3, v5.18-rc2
# 7ceeb601 07-Apr-2022 Linus Walleij <[email protected]>

mtd: maps: ixp4xx: Drop driver

This custom maps driver was never used with the device tree
enabled IXP4xx systems, which use the physmap add-on from
commit 2aba2f2a704d
("mtd: physmap_of: add a hook

mtd: maps: ixp4xx: Drop driver

This custom maps driver was never used with the device tree
enabled IXP4xx systems, which use the physmap add-on from
commit 2aba2f2a704d
("mtd: physmap_of: add a hook for Intel IXP4xx flash probing")

Since kernel v5.18-rc1 IXP4xx is only booting from the device
tree so drop this old driver.

Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]

show more ...


Revision tags: v5.18-rc1, v5.17, v5.17-rc8, v5.17-rc7, v5.17-rc6, v5.17-rc5, v5.17-rc4, v5.17-rc3, v5.17-rc2, v5.17-rc1, v5.16, v5.16-rc8, v5.16-rc7, v5.16-rc6, v5.16-rc5, v5.16-rc4
# 5a8df928 30-Nov-2021 Thomas Bogendoerfer <[email protected]>

MIPS: TXX9: Remove rbtx4939 board support

No active MIPS user own this board, so let's remove it.

Signed-off-by: Thomas Bogendoerfer <[email protected]>
Reviewed-by: Geert Uytterhoeven <gee

MIPS: TXX9: Remove rbtx4939 board support

No active MIPS user own this board, so let's remove it.

Signed-off-by: Thomas Bogendoerfer <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Tested-by: Geert Uytterhoeven <[email protected]>

show more ...


Revision tags: v5.16-rc3, v5.16-rc2, v5.16-rc1, v5.15, v5.15-rc7, v5.15-rc6, v5.15-rc5, v5.15-rc4, v5.15-rc3, v5.15-rc2, v5.15-rc1, v5.14, v5.14-rc7
# 60d06079 17-Aug-2021 Lukas Bulwahn <[email protected]>

mtd: maps: remove dead MTD map driver for PMC-Sierra MSP boards

Commit 1b00767fd8e1 ("MIPS: Remove PMC MSP71xx platform") removes the
config PMC_MSP in ./arch/mips/Kconfig.

Hence, since then, the c

mtd: maps: remove dead MTD map driver for PMC-Sierra MSP boards

Commit 1b00767fd8e1 ("MIPS: Remove PMC MSP71xx platform") removes the
config PMC_MSP in ./arch/mips/Kconfig.

Hence, since then, the corresponding MTD map driver for PMC-Sierra MSP
boards is dead code. Remove this dead driver.

Signed-off-by: Lukas Bulwahn <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]

show more ...


Revision tags: v5.14-rc6, v5.14-rc5, v5.14-rc4, v5.14-rc3, v5.14-rc2, v5.14-rc1, v5.13, v5.13-rc7, v5.13-rc6, v5.13-rc5, v5.13-rc4, v5.13-rc3, v5.13-rc2, v5.13-rc1, v5.12, v5.12-rc8, v5.12-rc7, v5.12-rc6, v5.12-rc5, v5.12-rc4, v5.12-rc3, v5.12-rc2, v5.12-rc1, v5.12-rc1-dontuse, v5.11, v5.11-rc7, v5.11-rc6, v5.11-rc5, v5.11-rc4, v5.11-rc3, v5.11-rc2, v5.11-rc1, v5.10, v5.10-rc7, v5.10-rc6, v5.10-rc5, v5.10-rc4, v5.10-rc3, v5.10-rc2, v5.10-rc1, v5.9, v5.9-rc8, v5.9-rc7, v5.9-rc6
# b3e79e76 20-Sep-2020 Serge Semin <[email protected]>

mtd: physmap: Add Baikal-T1 physically mapped ROM support

Baikal-T1 Boot Controller provides an access to a RO storages, which are
physically mapped into the SoC MMIO space. In particularly there ar

mtd: physmap: Add Baikal-T1 physically mapped ROM support

Baikal-T1 Boot Controller provides an access to a RO storages, which are
physically mapped into the SoC MMIO space. In particularly there are
Internal ROM embedded into the SoC with a pre-installed firmware,
externally attached SPI flash (also accessed in the read-only mode) and a
memory region, which mirrors one of them in accordance with the currently
enabled system boot mode (also called Boot ROM).

This commit adds the Internal ROM support to the physmap driver of the MTD
kernel subsystem. The driver will create the Internal ROM MTD as long as
it is defined in the system dts file. The physically mapped SPI flash
region will be used to implement the SPI-mem interface. The mirroring
memory region won't be accessible directly since it's redundant due to
both bootable regions being exposed anyway.

Note we had to create a dedicated code for the ROMs since read from the
corresponding memory regions must be done via the dword-aligned addresses.

Signed-off-by: Serge Semin <[email protected]>
Cc: Alexey Malahov <[email protected]>
Cc: Pavel Parkhomenko <[email protected]>
Cc: Lee Jones <[email protected]>
Cc: [email protected]
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]

show more ...


Revision tags: v5.9-rc5, v5.9-rc4, v5.9-rc3, v5.9-rc2, v5.9-rc1, v5.8, v5.8-rc7, v5.8-rc6, v5.8-rc5, v5.8-rc4, v5.8-rc3, v5.8-rc2, v5.8-rc1, v5.7, v5.7-rc7, v5.7-rc6, v5.7-rc5, v5.7-rc4, v5.7-rc3, v5.7-rc2, v5.7-rc1, v5.6, v5.6-rc7, v5.6-rc6, v5.6-rc5, v5.6-rc4, v5.6-rc3, v5.6-rc2, v5.6-rc1, v5.5, v5.5-rc7, v5.5-rc6, v5.5-rc5, v5.5-rc4, v5.5-rc3, v5.5-rc2, v5.5-rc1, v5.4, v5.4-rc8, v5.4-rc7, v5.4-rc6, v5.4-rc5
# 2aba2f2a 20-Oct-2019 Linus Walleij <[email protected]>

mtd: physmap_of: add a hook for Intel IXP4xx flash probing

In order to support device tree probing of IXP4xx NOR flash
chips, a certain big-endian or mixed-endian memory access
pattern need to be us

mtd: physmap_of: add a hook for Intel IXP4xx flash probing

In order to support device tree probing of IXP4xx NOR flash
chips, a certain big-endian or mixed-endian memory access
pattern need to be used.

I have opted to use the pattern set by previous plug-ins
to physmap for Gemini and Versatile, just override some
functions and reuse most of the physmap core code as it
is to minimize maintenance.

Parts of drivers/mtd/ixp4xx.c are copied into this file.

After we have IXP4xx converted fully to device tree, the
drivers/mtd/ixp4xx.c file will be deleted and this will
be the only access pattern to the IXP4xx flash.

I did not keep the quirk in the flash write function
after probe, where the old code for a while checks for
access to odd addresses, fails and assigns a "faster"
write function once it has convinced probe to only use
2-byte accesses. As we mandate that this device should
be using bank-width = <2> this should not be a problem
unless misconfigured.

Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>

show more ...


Revision tags: v5.4-rc4, v5.4-rc3, v5.4-rc2, v5.4-rc1, v5.3, v5.3-rc8, v5.3-rc7, v5.3-rc6, v5.3-rc5, v5.3-rc4, v5.3-rc3, v5.3-rc2, v5.3-rc1, v5.2, v5.2-rc7, v5.2-rc6, v5.2-rc5, v5.2-rc4, v5.2-rc3, v5.2-rc2, v5.2-rc1, v5.1, v5.1-rc7, v5.1-rc6, v5.1-rc5, v5.1-rc4, v5.1-rc3, v5.1-rc2, v5.1-rc1, v5.0, v5.0-rc8, v5.0-rc7, v5.0-rc6, v5.0-rc5, v5.0-rc4, v5.0-rc3, v5.0-rc2, v5.0-rc1, v4.20, v4.20-rc7, v4.20-rc6, v4.20-rc5, v4.20-rc4, v4.20-rc3, v4.20-rc2, v4.20-rc1, v4.19, v4.19-rc8, v4.19-rc7
# d24dbd75 04-Oct-2018 Boris Brezillon <[email protected]>

mtd: maps: Get rid of the latch-addr-flash driver

Looks like this driver was initially added to support the NOR on the
DA830-EVM (Davinci) board, but the board file update was never merged.

Keeping

mtd: maps: Get rid of the latch-addr-flash driver

Looks like this driver was initially added to support the NOR on the
DA830-EVM (Davinci) board, but the board file update was never merged.

Keeping unused drivers just adds to the maintenance burden, so let's
remove it if nobody uses it.

Cc: David Griego <[email protected]>
Cc: Aleksey Makarov <[email protected]>
Cc: Sergei Shtylyov <[email protected]>
Cc: Savinay Dharmappa <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
Acked-by: Sekhar Nori <[email protected]>

show more ...


# ba32ce95 19-Oct-2018 Boris Brezillon <[email protected]>

mtd: maps: Merge gpio-addr-flash.c into physmap-core.c

Controlling some MSB address lines using GPIOs is just a small
deviation from the generic physmap logic, and merging those two drivers
allows u

mtd: maps: Merge gpio-addr-flash.c into physmap-core.c

Controlling some MSB address lines using GPIOs is just a small
deviation from the generic physmap logic, and merging those two drivers
allows us to share most of the probe logic, which is a good thing.

Also, the gpio-addr-flash driver is unused since the removal of
the blackfin arch in v4.17, so we can safely remove the old driver
without risking breaking existing boards.

Signed-off-by: Boris Brezillon <[email protected]>
Reviewed-by: Ricardo Ribalda Delgado <[email protected]>
Tested-by: Ricardo Ribalda Delgado <[email protected]>
Acked-by: Linus Walleij <[email protected]>

show more ...


# 6ca15cfa 19-Oct-2018 Boris Brezillon <[email protected]>

mtd: maps: Rename physmap_of_{versatile, gemini} into physmap-{versatile, gemini}

Now that the physmap_of driver is gone, the gemini and versative
extensions are part of the physmap driver. Rename t

mtd: maps: Rename physmap_of_{versatile, gemini} into physmap-{versatile, gemini}

Now that the physmap_of driver is gone, the gemini and versative
extensions are part of the physmap driver. Rename the source files and
the config option to reflect this.

Signed-off-by: Boris Brezillon <[email protected]>
Reviewed-by: Ricardo Ribalda Delgado <[email protected]>
Acked-by: Linus Walleij <[email protected]>

show more ...


# 642b1e8d 19-Oct-2018 Boris Brezillon <[email protected]>

mtd: maps: Merge physmap_of.c into physmap-core.c

There's no real reason to have two separate driver for the DT and pdata
case. Just do what we do everywhere else and handle DT and pdata
parsing in

mtd: maps: Merge physmap_of.c into physmap-core.c

There's no real reason to have two separate driver for the DT and pdata
case. Just do what we do everywhere else and handle DT and pdata
parsing in the same driver.

Signed-off-by: Boris Brezillon <[email protected]>
Reviewed-by: Ricardo Ribalda Delgado <[email protected]>
Acked-by: Linus Walleij <[email protected]>

show more ...


# 0c3def9b 19-Oct-2018 Boris Brezillon <[email protected]>

mtd: maps: Prepare merging of physmap and physmap_of

We want to merge the physmap and physmap_of driver, but before we can
do that we must prepare things to create physmap.o out of several .c
files.

mtd: maps: Prepare merging of physmap and physmap_of

We want to merge the physmap and physmap_of driver, but before we can
do that we must prepare things to create physmap.o out of several .c
files. Rename physmap.c into physmap-core.c and add a new Makefile
rule to create physmap.o (right now it only contains physmap-core.o).

Signed-off-by: Boris Brezillon <[email protected]>
Reviewed-by: Ricardo Ribalda Delgado <[email protected]>
Acked-by: Linus Walleij <[email protected]>

show more ...


Revision tags: v4.19-rc6, v4.19-rc5, v4.19-rc4, v4.19-rc3, v4.19-rc2, v4.19-rc1, v4.18, v4.18-rc8, v4.18-rc7, v4.18-rc6, v4.18-rc5, v4.18-rc4, v4.18-rc3, v4.18-rc2, v4.18-rc1, v4.17, v4.17-rc7, v4.17-rc6, v4.17-rc5, v4.17-rc4, v4.17-rc3, v4.17-rc2, v4.17-rc1, v4.16, v4.16-rc7, v4.16-rc6
# 5741a164 14-Mar-2018 Arnd Bergmann <[email protected]>

mtd: maps: remove bfin-async-flash driver

The blackfin architecture is getting removed, so this driver
has become obsolete.

Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Boris Brezill

mtd: maps: remove bfin-async-flash driver

The blackfin architecture is getting removed, so this driver
has become obsolete.

Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>

show more ...


Revision tags: v4.16-rc5, v4.16-rc4, v4.16-rc3, v4.16-rc2, v4.16-rc1, v4.15, v4.15-rc9, v4.15-rc8, v4.15-rc7, v4.15-rc6, v4.15-rc5, v4.15-rc4, v4.15-rc3, v4.15-rc2, v4.15-rc1, v4.14, v4.14-rc8
# b2441318 01-Nov-2017 Greg Kroah-Hartman <[email protected]>

License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine

License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.

By default all files without license information are under the default
license of the kernel, which is GPL version 2.

Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.

This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.

How this work was done:

Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,

Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.

The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.

The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.

Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).

All documentation files were explicitly excluded.

The following heuristics were used to determine which SPDX license
identifiers to apply.

- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.

For non */uapi/* files that summary was:

SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139

and resulted in the first patch in this series.

If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:

SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930

and resulted in the second patch in this series.

- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:

SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1

and that resulted in the third patch in this series.

- when the two scanners agreed on the detected license(s), that became
the concluded license(s).

- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.

- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).

- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.

- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.

In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.

Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.

Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.

In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.

Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct

This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.

These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.

Reviewed-by: Kate Stewart <[email protected]>
Reviewed-by: Philippe Ombredanne <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...


Revision tags: v4.14-rc7, v4.14-rc6, v4.14-rc5, v4.14-rc4, v4.14-rc3, v4.14-rc2, v4.14-rc1, v4.13, v4.13-rc7, v4.13-rc6, v4.13-rc5, v4.13-rc4, v4.13-rc3, v4.13-rc2, v4.13-rc1, v4.12, v4.12-rc7, v4.12-rc6, v4.12-rc5, v4.12-rc4, v4.12-rc3, v4.12-rc2, v4.12-rc1, v4.11, v4.11-rc8, v4.11-rc7, v4.11-rc6, v4.11-rc5
# 8c925b26 30-Mar-2017 Linus Walleij <[email protected]>

mtd: physmap_of: really fix the physmap add-ons

The current way of building the of_physmap add-ons result in just
the add-on being in the object code, and not the actual core
implementation and regr

mtd: physmap_of: really fix the physmap add-ons

The current way of building the of_physmap add-ons result in just
the add-on being in the object code, and not the actual core
implementation and regress the Gemini and Versatile.

Bake the physmap_of.o object by baking physmap_of_core.o and
adding the Versatile and/or Gemini add-ons to the final object.
Rename the source file physmap_of_core.c to get the desired
build components.

Suggested-by: Boris Brezillon <[email protected]>
Fixes: 4f04f68e1598 ("mtd: physmap_of: fixup gemini/versatile dependencies")
Signed-off-by: Linus Walleij <[email protected]>
Acked-by: Boris Brezillon <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

show more ...


Revision tags: v4.11-rc4, v4.11-rc3, v4.11-rc2, v4.11-rc1, v4.10, v4.10-rc8
# 4f04f68e 09-Feb-2017 Brian Norris <[email protected]>

mtd: physmap_of: fixup gemini/versatile dependencies

physmap_of sort of depends on the gemini and versatile modules (when
they're enabled), but this isn't expressed in Kconfig. Let's just merge
the

mtd: physmap_of: fixup gemini/versatile dependencies

physmap_of sort of depends on the gemini and versatile modules (when
they're enabled), but this isn't expressed in Kconfig. Let's just merge
the modules all together, when enabled. Then we can avoid exporting a
few symbols, and the versatile and gemini code can now be modular again
(the below commit accidentally made them built-in only).

Resolves errors like this:

ERROR: "of_flash_probe_versatile" [drivers/mtd/maps/physmap_of.ko] undefined!
ERROR: "of_flash_probe_gemini" [drivers/mtd/maps/physmap_of.ko] undefined!

Fixes: 56ff337ea433 ("mtd: physmap_of: add a hook for Gemini flash probing")
Cc: Linus Walleij <[email protected]>
Signed-off-by: Brian Norris <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>

show more ...


Revision tags: v4.10-rc7, v4.10-rc6
# 56ff337e 28-Jan-2017 Linus Walleij <[email protected]>

mtd: physmap_of: add a hook for Gemini flash probing

In order to support device tree probing of Gemini NOR flash
chips, a certain register in the syscon needs to be poked
to enable parallel flash mo

mtd: physmap_of: add a hook for Gemini flash probing

In order to support device tree probing of Gemini NOR flash
chips, a certain register in the syscon needs to be poked
to enable parallel flash mode.

Such things used to happen in "necessarily different" board
file code, and this indeed was also done for the Gemini, so
the MTD driver could treat it as any memory-mapped NOR flash,
but this is not the way in the future: board files need to
go, and hardware concerns distributed down to the applicable
drivers.

This adds a hook in the same way that the Versatile did: if
the Kconfig symbol is not selected the net total of supporting
Gemini should be zero bytes of added code. To live up to this
promise, also the return value error print from the Versatile
extra probe call get to be removed in this patch, all printing
need to happen in the add-ons.

Cc: Janos Laube <[email protected]>
Cc: Paulius Zaleckas <[email protected]>
Cc: Hans Ulli Kroll <[email protected]>
Cc: Florian Fainelli <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Acked-by: Marek Vasut <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

show more ...


Revision tags: v4.10-rc5, v4.10-rc4, v4.10-rc3, v4.10-rc2, v4.10-rc1, v4.9, v4.9-rc8, v4.9-rc7, v4.9-rc6, v4.9-rc5, v4.9-rc4, v4.9-rc3, v4.9-rc2, v4.9-rc1, v4.8, v4.8-rc8, v4.8-rc7, v4.8-rc6, v4.8-rc5, v4.8-rc4, v4.8-rc3, v4.8-rc2, v4.8-rc1, v4.7, v4.7-rc7, v4.7-rc6, v4.7-rc5, v4.7-rc4, v4.7-rc3, v4.7-rc2, v4.7-rc1, v4.6, v4.6-rc7, v4.6-rc6
# c5f9d6b1 25-Apr-2016 Arnd Bergmann <[email protected]>

physmap_of: ensure versatile code is reachable

With the newly added physmap_of_versatile code, we get a build error
when physmap_of is in a module, because of_flash_probe_versatile
is not exported:

physmap_of: ensure versatile code is reachable

With the newly added physmap_of_versatile code, we get a build error
when physmap_of is in a module, because of_flash_probe_versatile
is not exported:

ERROR: "of_flash_probe_versatile" [drivers/mtd/maps/physmap_of.ko] undefined!

This adds the export, and changes the Makefile so that the code is
also put into a loadable module rather than built-in when physmap_of
itself is a module.

Signed-off-by: Arnd Bergmann <[email protected]>

show more ...


Revision tags: v4.6-rc5, v4.6-rc4, v4.6-rc3, v4.6-rc2, v4.6-rc1, v4.5, v4.5-rc7, v4.5-rc6, v4.5-rc5, v4.5-rc4, v4.5-rc3, v4.5-rc2
# b0afd44b 26-Jan-2016 Linus Walleij <[email protected]>

mtd: physmap_of: add a hook for Versatile write protection

In order to support device tree probing of Versatile NOR flash
chips, there must be a way to add the VPP (write protection)
enable/disable

mtd: physmap_of: add a hook for Versatile write protection

In order to support device tree probing of Versatile NOR flash
chips, there must be a way to add the VPP (write protection)
enable/disable callback. The register in question is in the
system controllers of these machines. Apart from this quirk,
the ARM flash chips are standard CFI flash chips from various
vendors.

Additionally, the Integrator/AP require you to set up the external
bus interface (EBI) to allow writes to the chip select where the
flash memory is connected.

Solve this by looking for the arm,versatile-flash compatible
string in the flash device tree node. In the driver,
add a special hook to check for the various Versatile syscons and
register a callback for .set_vpp() if this compatible is present.

Provide a special Kconfig entry for the addon hook so it will
not be compiled in if the Versatile boards are not supported.
Stubs in the header file make sure the impact will be zero on
other platforms. (Compilers optimze this out.)

With this patch, a large slew of ARM board file code can be
removed.

Cc: Grant Likely <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>

show more ...


Revision tags: v4.5-rc1, v4.4, v4.4-rc8, v4.4-rc7, v4.4-rc6, v4.4-rc5, v4.4-rc4, v4.4-rc3, v4.4-rc2, v4.4-rc1, v4.3, v4.3-rc7, v4.3-rc6, v4.3-rc5, v4.3-rc4, v4.3-rc3, v4.3-rc2, v4.3-rc1, v4.2, v4.2-rc8, v4.2-rc7, v4.2-rc6, v4.2-rc5, v4.2-rc4, v4.2-rc3, v4.2-rc2, v4.2-rc1, v4.1, v4.1-rc8, v4.1-rc7, v4.1-rc6, v4.1-rc5, v4.1-rc4, v4.1-rc3, v4.1-rc2, v4.1-rc1, v4.0, v4.0-rc7, v4.0-rc6, v4.0-rc5, v4.0-rc4, v4.0-rc3, v4.0-rc2, v4.0-rc1, v3.19, v3.19-rc7, v3.19-rc6, v3.19-rc5, v3.19-rc4, v3.19-rc3, v3.19-rc2, v3.19-rc1, v3.18, v3.18-rc7, v3.18-rc6, v3.18-rc5, v3.18-rc4, v3.18-rc3, v3.18-rc2, v3.18-rc1, v3.17, v3.17-rc7, v3.17-rc6, v3.17-rc5, v3.17-rc4, v3.17-rc3, v3.17-rc2, v3.17-rc1, v3.16, v3.16-rc7, v3.16-rc6, v3.16-rc5, v3.16-rc4, v3.16-rc3, v3.16-rc2, v3.16-rc1, v3.15, v3.15-rc8, v3.15-rc7, v3.15-rc6, v3.15-rc5, v3.15-rc4, v3.15-rc3, v3.15-rc2, v3.15-rc1, v3.14, v3.14-rc8, v3.14-rc7, v3.14-rc6, v3.14-rc5, v3.14-rc4, v3.14-rc3, v3.14-rc2, v3.14-rc1, v3.13, v3.13-rc8, v3.13-rc7, v3.13-rc6, v3.13-rc5, v3.13-rc4, v3.13-rc3, v3.13-rc2, v3.13-rc1, v3.12, v3.12-rc7, v3.12-rc6, v3.12-rc5, v3.12-rc4, v3.12-rc3, v3.12-rc2, v3.12-rc1, v3.11, v3.11-rc7, v3.11-rc6, v3.11-rc5, v3.11-rc4, v3.11-rc3, v3.11-rc2, v3.11-rc1, v3.10, v3.10-rc7, v3.10-rc6, v3.10-rc5, v3.10-rc4, v3.10-rc3, v3.10-rc2
# 795add9a 13-May-2013 Paul Bolle <[email protected]>

mtd: remove obsolete JEDEC mapping drivers

JEDEC device support was removed in v2.6.22. (It had been marked as
BROKEN (indirectly) since at least v2.6.12.)

When it was removed the two JEDEC mapping

mtd: remove obsolete JEDEC mapping drivers

JEDEC device support was removed in v2.6.22. (It had been marked as
BROKEN (indirectly) since at least v2.6.12.)

When it was removed the two JEDEC mapping drivers that depended on it
should have been removed too. Do so now.

Signed-off-by: Paul Bolle <[email protected]>
Acked-by: Brian Norris <[email protected]>
Signed-off-by: Artem Bityutskiy <[email protected]>
Signed-off-by: David Woodhouse <[email protected]>

show more ...


# d29268ce 13-May-2013 Alexander Shiyan <[email protected]>

ARM: clps711x: autcpu12: Special driver for handling memory is removed

This patch provide migration to using "mtd-ram" driver instead of using
special driver for handling NVRAM memory.

Signed-off-b

ARM: clps711x: autcpu12: Special driver for handling memory is removed

This patch provide migration to using "mtd-ram" driver instead of using
special driver for handling NVRAM memory.

Signed-off-by: Alexander Shiyan <[email protected]>
Signed-off-by: Olof Johansson <[email protected]>

show more ...


Revision tags: v3.10-rc1, v3.9, v3.9-rc8, v3.9-rc7, v3.9-rc6, v3.9-rc5, v3.9-rc4, v3.9-rc3
# dcf8abfc 14-Mar-2013 Arnd Bergmann <[email protected]>

mtd: remove h720x flash support

The h720x platform support is going away in linux-3.10, so the
MTD driver will also not be needed any more.

Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-b

mtd: remove h720x flash support

The h720x platform support is going away in linux-3.10, so the
MTD driver will also not be needed any more.

Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Artem Bityutskiy <[email protected]>
Signed-off-by: David Woodhouse <[email protected]>

show more ...


# b08a25ad 11-Mar-2013 Artem Bityutskiy <[email protected]>

mtd: remove the ixp2000 map driver

This driver depends on CONFIG_IXP2000 which is not defined anywhere, which
means this driver is dead.

Signed-off-by: Artem Bityutskiy <[email protected]

mtd: remove the ixp2000 map driver

This driver depends on CONFIG_IXP2000 which is not defined anywhere, which
means this driver is dead.

Signed-off-by: Artem Bityutskiy <[email protected]>
Signed-off-by: David Woodhouse <[email protected]>

show more ...


# bece641c 11-Mar-2013 Artem Bityutskiy <[email protected]>

mtd: remove the dilnetpc map driver support

This driver is marked as broken for very long time. Most probably this board is
just something ancient no one cares about anyway.

Signed-off-by: Artem Bi

mtd: remove the dilnetpc map driver support

This driver is marked as broken for very long time. Most probably this board is
just something ancient no one cares about anyway.

Signed-off-by: Artem Bityutskiy <[email protected]>
Signed-off-by: David Woodhouse <[email protected]>

show more ...


# a312c87a 11-Mar-2013 Artem Bityutskiy <[email protected]>

mtd: remove the tqm8xxl map driver

This driver depends on the CONFIG_TQM8xxL symbol, which is not defined
anywhere, which means that this driver is dead.

Signed-off-by: Artem Bityutskiy <artem.bity

mtd: remove the tqm8xxl map driver

This driver depends on the CONFIG_TQM8xxL symbol, which is not defined
anywhere, which means that this driver is dead.

Signed-off-by: Artem Bityutskiy <[email protected]>
Signed-off-by: David Woodhouse <[email protected]>

show more ...


1234