- 15 Oct, 2021 14 commits
-
-
Miquel Raynal authored
Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: 8fc6f1f0 ("mtd: rawnand: pasemi: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-7-miquel.raynal@bootlin.com
-
Miquel Raynal authored
Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: 553508ce ("mtd: rawnand: orion: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by:
-
Miquel Raynal authored
Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: 6dd09f77 ("mtd: rawnand: mpc5121: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by:
-
Miquel Raynal authored
Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: f6341f64 ("mtd: rawnand: gpio: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by:
-
Miquel Raynal authored
Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: dbffc8cc ("mtd: rawnand: au1550: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by:
-
Miquel Raynal authored
Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: 59d93473 ("mtd: rawnand: ams-delta: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by:
-
Miquel Raynal authored
This reverts commit 56a8d3fd. Before the introduction of the ECC framework infrastructure, many drivers used the ->calculate/correct() Hamming helpers directly. The point of this framework was to avoid this kind of hackish calls and use a proper and generic API but it is true that in certain cases, drivers still need to use these helpers in order to do ECC computations on behalf of their limited hardware. Right after the introduction of the ECC engine core introduction, it was spotted that it was not possible to use the shiny rawnand software ECC helpers so easily because an ECC engine object should have been allocated and initialized first. While this works well in most cases, for these drivers just leveraging the power of a single helper in conjunction with some pretty old and limited hardware, it did not fit. The idea back then was to declare intermediate helpers which would make use of the exported software ECC engine bare functions while keeping the rawnand layer compatibility. As there was already functions with the rawnand_sw_hamming_ prefix it was decided to declare new local helpers for this purpose in each driver needing one. Besides being far from optimal, this design choice was blamed by Linus when he pulled the "fixes" pull request [1] so that is why now it is time to clean this mess up. The implementation of the rawnand_ecc_sw_* helpers has now been enhanced to support both cases, when the ECC object is instantiated and when it is not. This way, we can still use the existing and exported rawnand helpers while avoiding the need for each driver to declare its own helper, thus this fix from [2] can now be safely reverted. [1] https://lore.kernel.org/lkml/CAHk-=wh_ZHF685Fni8V9is17mj=pFisUaZ_0=gq6nbK+ZcyQmg@mail.gmail.com/ [2] https://lore.kernel.org/linux-mtd/20210413161840.345208-1-miquel.raynal@bootlin.comSigned-off-by:
-
Miquel Raynal authored
This reverts commit c4b7d7c4. Before the introduction of the ECC framework infrastructure, many drivers used the ->calculate/correct() Hamming helpers directly. The point of this framework was to avoid this kind of hackish calls and use a proper and generic API but it is true that in certain cases, drivers still need to use these helpers in order to do ECC computations on behalf of their limited hardware. Right after the introduction of the ECC engine core introduction, it was spotted that it was not possible to use the shiny rawnand software ECC helpers so easily because an ECC engine object should have been allocated and initialized first. While this works well in most cases, for these drivers just leveraging the power of a single helper in conjunction with some pretty old and limited hardware, it did not fit. The idea back then was to declare intermediate helpers which would make use of the exported software ECC engine bare functions while keeping the rawnand layer compatibility. As there was already functions with the rawnand_sw_hamming_ prefix it was decided to declare new local helpers for this purpose in each driver needing one. Besides being far from optimal, this design choice was blamed by Linus when he pulled the "fixes" pull request [1] so that is why now it is time to clean this mess up. The implementation of the rawnand_ecc_sw_* helpers has now been enhanced to support both cases, when the ECC object is instantiated and when it is not. This way, we can still use the existing and exported rawnand helpers while avoiding the need for each driver to declare its own helper, thus this fix from [2] can now be safely reverted. [1] https://lore.kernel.org/lkml/CAHk-=wh_ZHF685Fni8V9is17mj=pFisUaZ_0=gq6nbK+ZcyQmg@mail.gmail.com/ [2] https://lore.kernel.org/linux-mtd/20210413161840.345208-1-miquel.raynal@bootlin.comSigned-off-by:
-
Miquel Raynal authored
This reverts commit 3e09c025. Before the introduction of the ECC framework infrastructure, many drivers used the ->calculate/correct() Hamming helpers directly. The point of this framework was to avoid this kind of hackish calls and use a proper and generic API but it is true that in certain cases, drivers still need to use these helpers in order to do ECC computations on behalf of their limited hardware. Right after the introduction of the ECC engine core introduction, it was spotted that it was not possible to use the shiny rawnand software ECC helpers so easily because an ECC engine object should have been allocated and initialized first. While this works well in most cases, for these drivers just leveraging the power of a single helper in conjunction with some pretty old and limited hardware, it did not fit. The idea back then was to declare intermediate helpers which would make use of the exported software ECC engine bare functions while keeping the rawnand layer compatibility. As there was already functions with the rawnand_sw_hamming_ prefix it was decided to declare new local helpers for this purpose in each driver needing one. Besides being far from optimal, this design choice was blamed by Linus when he pulled the "fixes" pull request [1] so that is why now it is time to clean this mess up. The implementation of the rawnand_ecc_sw_* helpers has now been enhanced to support both cases, when the ECC object is instantiated and when it is not. This way, we can still use the existing and exported rawnand helpers while avoiding the need for each driver to declare its own helper, thus this fix from [2] can now be safely reverted. [1] https://lore.kernel.org/lkml/CAHk-=wh_ZHF685Fni8V9is17mj=pFisUaZ_0=gq6nbK+ZcyQmg@mail.gmail.com/ [2] https://lore.kernel.org/linux-mtd/20210413161840.345208-1-miquel.raynal@bootlin.comSigned-off-by:
-
Miquel Raynal authored
This reverts commit 46fcb57e. Before the introduction of the ECC framework infrastructure, many drivers used the ->calculate/correct() Hamming helpers directly. The point of this framework was to avoid this kind of hackish calls and use a proper and generic API but it is true that in certain cases, drivers still need to use these helpers in order to do ECC computations on behalf of their limited hardware. Right after the introduction of the ECC engine core introduction, it was spotted that it was not possible to use the shiny rawnand software ECC helpers so easily because an ECC engine object should have been allocated and initialized first. While this works well in most cases, for these drivers just leveraging the power of a single helper in conjunction with some pretty old and limited hardware, it did not fit. The idea back then was to declare intermediate helpers which would make use of the exported software ECC engine bare functions while keeping the rawnand layer compatibility. As there was already functions with the rawnand_sw_hamming_ prefix it was decided to declare new local helpers for this purpose in each driver needing one. Besides being far from optimal, this design choice was blamed by Linus when he pulled the "fixes" pull request [1] so that is why now it is time to clean this mess up. The implementation of the rawnand_ecc_sw_* helpers has now been enhanced to support both cases, when the ECC object is instantiated and when it is not. This way, we can still use the existing and exported rawnand helpers while avoiding the need for each driver to declare its own helper, thus this fix from [2] can now be safely reverted. [1] https://lore.kernel.org/lkml/CAHk-=wh_ZHF685Fni8V9is17mj=pFisUaZ_0=gq6nbK+ZcyQmg@mail.gmail.com/ [2] https://lore.kernel.org/linux-mtd/20210413161840.345208-1-miquel.raynal@bootlin.comSigned-off-by:
-
Miquel Raynal authored
This reverts commit 6a4c5ada. Before the introduction of the ECC framework infrastructure, many drivers used the ->calculate/correct() Hamming helpers directly. The point of this framework was to avoid this kind of hackish calls and use a proper and generic API but it is true that in certain cases, drivers still need to use these helpers in order to do ECC computations on behalf of their limited hardware. Right after the introduction of the ECC engine core introduction, it was spotted that it was not possible to use the shiny rawnand software ECC helpers so easily because an ECC engine object should have been allocated and initialized first. While this works well in most cases, for these drivers just leveraging the power of a single helper in conjunction with some pretty old and limited hardware, it did not fit. The idea back then was to declare intermediate helpers which would make use of the exported software ECC engine bare functions while keeping the rawnand layer compatibility. As there was already functions with the rawnand_sw_hamming_ prefix it was decided to declare new local helpers for this purpose in each driver needing one. Besides being far from optimal, this design choice was blamed by Linus when he pulled the "fixes" pull request [1] so that is why now it is time to clean this mess up. The implementation of the rawnand_ecc_sw_* helpers has now been enhanced to support both cases, when the ECC object is instantiated and when it is not. This way, we can still use the existing and exported rawnand helpers while avoiding the need for each driver to declare its own helper, thus this fix from [2] can now be safely reverted. [1] https://lore.kernel.org/lkml/CAHk-=wh_ZHF685Fni8V9is17mj=pFisUaZ_0=gq6nbK+ZcyQmg@mail.gmail.com/ [2] https://lore.kernel.org/linux-mtd/20210413161840.345208-1-miquel.raynal@bootlin.comSigned-off-by:
-
Miquel Raynal authored
This reverts commit 3d227a0b. Before the introduction of the ECC framework infrastructure, many drivers used the ->calculate/correct() Hamming helpers directly. The point of this framework was to avoid this kind of hackish calls and use a proper and generic API but it is true that in certain cases, drivers still need to use these helpers in order to do ECC computations on behalf of their limited hardware. Right after the introduction of the ECC engine core introduction, it was spotted that it was not possible to use the shiny rawnand software ECC helpers so easily because an ECC engine object should have been allocated and initialized first. While this works well in most cases, for these drivers just leveraging the power of a single helper in conjunction with some pretty old and limited hardware, it did not fit. The idea back then was to declare intermediate helpers which would make use of the exported software ECC engine bare functions while keeping the rawnand layer compatibility. As there was already functions with the rawnand_sw_hamming_ prefix it was decided to declare new local helpers for this purpose in each driver needing one. Besides being far from optimal, this design choice was blamed by Linus when he pulled the "fixes" pull request [1] so that is why now it is time to clean this mess up. The implementation of the rawnand_ecc_sw_* helpers has now been enhanced to support both cases, when the ECC object is instantiated and when it is not. This way, we can still use the existing and exported rawnand helpers while avoiding the need for each driver to declare its own helper, thus this fix from [2] can now be safely reverted. [1] https://lore.kernel.org/lkml/CAHk-=wh_ZHF685Fni8V9is17mj=pFisUaZ_0=gq6nbK+ZcyQmg@mail.gmail.com/ [2] https://lore.kernel.org/linux-mtd/20210413161840.345208-1-miquel.raynal@bootlin.comSigned-off-by:
-
Miquel Raynal authored
Before the introduction of the ECC framework infrastructure, many drivers used the ->calculate/correct() Hamming helpers directly. The point of this framework was to avoid this kind of hackish calls and use a proper and generic API but it is true that in certain cases, drivers still need to use these helpers in order to do ECC computations on behalf of their limited hardware. Right after the introduction of the ECC engine core introduction, it was spotted that it was not possible to use the shiny rawnand software ECC helpers so easily because an ECC engine object should have been allocated and initialized first. While this works well in most cases, for these drivers just leveraging the power of a single helper in conjunction with some pretty old and limited hardware, it did not fit. The idea back then was to declare intermediate helpers which would make use of the exported software ECC engine bare functions while keeping the rawnand layer compatibility. As there was already functions with the rawnand_sw_hamming_ prefix it was decided to declare new local helpers for this purpose in each driver needing one. Besides being far from optimal, this design choice was blamed by Linus when he pulled the "fixes" pull request [1] so that is why now it is time to clean this mess up. Enhancing the implementation of the rawnand_ecc_sw_* helpers to support both cases, when the ECC object is instantiated and when it is not is a quite elegant way to solve this situation. This way, we can still use the existing and exported rawnand helpers while avoiding the need for each driver to declare its own helper. Following this change, most of the fixes sent in [2] can now be safely reverted. Only the fsmc fix will need to be kept because there is actually something specific to the driver to do in its ->correct() helper. [1] https://lore.kernel.org/lkml/CAHk-=wh_ZHF685Fni8V9is17mj=pFisUaZ_0=gq6nbK+ZcyQmg@mail.gmail.com/ [2] https://lore.kernel.org/linux-mtd/20210413161840.345208-1-miquel.raynal@bootlin.com/Signed-off-by:
-
Miquel Raynal authored
The introduction of the generic ECC engine API lead to a number of changes in various drivers which broke some of them. Here is a typical example: I expected the SM_ORDER option to be handled by the Hamming ECC engine internals. Problem: the fsmc driver does not instantiate (yet) a real ECC engine object so we had to use a 'bare' ECC helper instead of the shiny rawnand functions. However, when not intializing this engine properly and using the bare helpers, we do not get the SM ORDER feature handled automatically. It looks like this was lost in the process so let's ensure we use the right SM ORDER now. Fixes: ad9ffdce ("mtd: rawnand: fsmc: Fix external use of SW Hamming ECC helper") Cc: stable@vger.kernel.org Signed-off-by:
-
- 28 Sep, 2021 1 commit
-
-
Krzysztof Kozlowski authored
None of supported Samsung Exynos4 SoCs (Exynos4210, Exynos4412) seem to use OneNAND driver so drop it. Describe better which driver applies to which SoC, to make configuring kernel for Samsung SoC easier. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by:
-
- 14 Sep, 2021 18 commits
-
-
Evgeny Novikov authored
ebu_nand_probe() read the value of u32 variable "cs" from the device firmware description and used it as the index for array ebu_host->cs that can contain MAX_CS (2) elements at most. That could result in a buffer overflow and various bad consequences later. Fix the potential buffer overflow by restricting values of "cs" with MAX_CS in probe. Found by Linux Driver Verification project (linuxtesting.org). Fixes: 0b1039f0 ("mtd: rawnand: Add NAND controller support on Intel LGM SoC") Signed-off-by:
Evgeny Novikov <novikov@ispras.ru> Co-developed-by:
Kirill Shilimanov <kirill.shilimanov@huawei.com> Signed-off-by:
Anton Vasilyev <vasilyev@ispras.ru> Signed-off-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by:
Cai Huoqing <caihuoqing@baidu.com> Signed-off-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by:
Christophe Kerello <christophe.kerello@foss.st.com> Signed-off-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource_byname() helper instead of calling platform_get_resource_byname() and devm_ioremap_resource() separately Signed-off-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource_byname() helper instead of calling platform_get_resource_byname() and devm_ioremap_resource() separately Signed-off-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource_byname() helper instead of calling platform_get_resource_byname() and devm_ioremap_resource() separately Signed-off-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by:
-
GONG, Ruiqi authored
All uses of MTD_MAX_{OOBFREE,ECCPOS}_ENTRIES_LARGE have been removed as commit ef5eeea6 ("mtd: nand: brcm: switch to mtd_ooblayout_ops") and commit aab616e3 ("mtd: kill the nand_ecclayout struct") replaced struct nand_ecclayout by the new mtd_ooblayout_ops interface. Remove these two macros therefore. Reported-by:Yi Yang <yiyang13@huawei.com> Signed-off-by:
GONG, Ruiqi <gongruiqi1@huawei.com> Signed-off-by:
-
- 12 Sep, 2021 7 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
Merge tag 'perf-tools-for-v5.15-2021-09-11' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux Pull more perf tools updates from Arnaldo Carvalho de Melo: - Add missing fields and remove some duplicate fields when printing a perf_event_attr. - Fix hybrid config terms list corruption. - Update kernel header copies, some resulted in new kernel features being automagically added to 'perf trace' syscall/tracepoint argument id->string translators. - Add a file generated during the documentation build to .gitignore. - Add an option to build without libbfd, as some distros, like Debian consider its ABI unstable. - Add support to print a textual representation of IBS raw sample data in 'perf report'. - Fix bpf 'perf test' sample mismatch reporting - Fix passing arguments to stackcollapse report in a 'perf script' python script. - Allow build-id with trailing zeros. - Look for ImageBase in PE file to compute .text offset. * tag 'perf-tools-for-v5.15-2021-09-11' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux: (25 commits) tools headers UAPI: Update tools's copy of drm.h headers tools headers UAPI: Sync drm/i915_drm.h with the kernel sources tools headers UAPI: Sync linux/fs.h with the kernel sources tools headers UAPI: Sync linux/in.h copy with the kernel sources perf tools: Add an option to build without libbfd perf tools: Allow build-id with trailing zeros perf tools: Fix hybrid config terms list corruption perf tools: Factor out copy_config_terms() and free_config_terms() perf tools: Fix perf_event_attr__fprintf() missing/dupl. fields perf tools: Ignore Documentation dependency file perf bpf: Provide a weak btf__load_from_kernel_by_id() for older libbpf versions tools include UAPI: Update linux/mount.h copy perf beauty: Cover more flags in the move_mount syscall argument beautifier tools headers UAPI: Sync linux/prctl.h with the kernel sources tools include UAPI: Sync sound/asound.h copy with the kernel sources tools headers UAPI: Sync linux/kvm.h with the kernel sources tools headers UAPI: Sync x86's asm/kvm.h with the kernel sources perf report: Add support to print a textual representation of IBS raw sample data perf report: Add tools/arch/x86/include/asm/amd-ibs.h perf env: Add perf_env__cpuid, perf_env__{nr_}pmu_mappings ...
-
git://github.com/ojeda/linuxLinus Torvalds authored
Pull compiler attributes updates from Miguel Ojeda: - Fix __has_attribute(__no_sanitize_coverage__) for GCC 4 (Marco Elver) - Add Nick as Reviewer for compiler_attributes.h (Nick Desaulniers) - Move __compiletime_{error|warning} (Nick Desaulniers) * tag 'compiler-attributes-for-linus-v5.15-rc1-v2' of git://github.com/ojeda/linux: compiler_attributes.h: move __compiletime_{error|warning} MAINTAINERS: add Nick as Reviewer for compiler_attributes.h Compiler Attributes: fix __has_attribute(__no_sanitize_coverage__) for GCC 4 -
git://github.com/ojeda/linuxLinus Torvalds authored
Pull auxdisplay updates from Miguel Ojeda: "An assortment of improvements for auxdisplay: - Replace symbolic permissions with octal permissions (Jinchao Wang) - ks0108: Switch to use module_parport_driver() (Andy Shevchenko) - charlcd: Drop unneeded initializers and switch to C99 style (Andy Shevchenko) - hd44780: Fix oops on module unloading (Lars Poeschel) - Add I2C gpio expander example (Ralf Schlatterbeck)" * tag 'auxdisplay-for-linus-v5.15-rc1' of git://github.com/ojeda/linux: auxdisplay: Replace symbolic permissions with octal permissions auxdisplay: ks0108: Switch to use module_parport_driver() auxdisplay: charlcd: Drop unneeded initializers and switch to C99 style auxdisplay: hd44780: Fix oops on module unloading auxdisplay: Add I2C gpio expander example -
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull CPU hotplug updates from Thomas Gleixner: "Updates for the SMP and CPU hotplug: - Remove DEFINE_SMP_CALL_CACHE_FUNCTION() which is a left over of the original hotplug code and now causing trouble with the ARM64 cache topology setup due to the pointless SMP function call. It's not longer required as the hotplug callbacks are guaranteed to be invoked on the upcoming CPU. - Remove the deprecated and now unused CPU hotplug functions - Rewrite the CPU hotplug API documentation" * tag 'smp-urgent-2021-09-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: Documentation: core-api/cpuhotplug: Rewrite the API section cpu/hotplug: Remove deprecated CPU-hotplug functions. thermal: Replace deprecated CPU-hotplug functions. drivers: base: cacheinfo: Get rid of DEFINE_SMP_CALL_CACHE_FUNCTION() -
Linus Torvalds authored
Merge tag 'char-misc-5.15-rc1-lkdtm' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull misc driver fix from Greg KH: "Here is a single patch for 5.15-rc1, for the lkdtm misc driver. It resolves a build issue that many people were hitting with your current tree, and Kees and others felt would be good to get merged before -rc1 comes out, to prevent them from having to constantly hit it as many development trees restart on -rc1, not older -rc releases. It has NOT been in linux-next, but has passed 0-day testing and looks 'obviously correct' when reviewing it locally :)" * tag 'char-misc-5.15-rc1-lkdtm' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: lkdtm: Use init_uts_ns.name instead of macros
-
git://github.com/cminyard/linux-ipmiLinus Torvalds authored
Pull IPMI updates from Corey Minyard: "A couple of very minor fixes for style and rate limiting. Nothing big, but probably needs to go in" * tag 'for-linus-5.15-1' of git://github.com/cminyard/linux-ipmi: char: ipmi: use DEVICE_ATTR helper macro ipmi: rate limit ipmi smi_event failure message
-
