- 05 Apr, 2023 5 commits
-
-
Jiaxun Yang authored
cpu_has_octeon_cache was tied to 0 for generic cpu-features, whith this generic kernel built for octeon CPU won't boot. Just enable this flag by cpu_type. It won't hurt orther platforms because compiler will eliminate the code path on other processors. Signed-off-by:
Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by:
Thomas Bogendoerfer <tsbogend@alpha.franken.de>
-
Jiaxun Yang authored
Octeon has a different cache interface with traditional R4K one, just opt-out this flag for octeon to avoid run R4K cache initialization code accidentally. Also remove ISA level assumption for 4k cache. Signed-off-by:
-
Jiaxun Yang authored
Prevent reading unsupported config register during probing process. Signed-off-by:
-
Jiaxun Yang authored
We don't know how to do coherence setup on ISA before MIPS Release 1. As CPS support only servers simulation purpose on those cores, and simulators are always coherent, just disable initialization code and provide user a warning in case coherence is not setup properly. Signed-off-by:
-
Jiaxun Yang authored
bcache is not tied to CPU's cache interface. Just move those declaration to cache.c so it can be avaialble to CPU with all cache types. Signed-off-by:
-
- 27 Mar, 2023 1 commit
-
-
Thomas Bogendoerfer authored
Commit ed6a0b6e ("MIPS: octeon: Use of_address_to_resource()") lost a cast, which causes a compile error. Fixes: ed6a0b6e ("MIPS: octeon: Use of_address_to_resource()") Signed-off-by:
-
- 24 Mar, 2023 5 commits
-
-
Jiaxun Yang authored
As nowadays DMA coherence is managed per device, it is possible to have a system that is defaulted to coherent dma but still have noncoherent device that needs to use those flush functions. Just install them unconditionally. Signed-off-by:
-
Jiaxun Yang authored
As now we are telling the necessity of post DMA flush per CPU type, there is no need to select ARCH_HAS_SYNC_DMA_FOR_CPU on per platform bias, just select it unconditionally and we can sort it at runtime. Signed-off-by:
-
Jiaxun Yang authored
arch_setup_dma_ops on MIPS sets coherency information in struct device. It's essential for per-device coherency to work. Select it for all non-coherent platforms. Signed-off-by:
-
Rob Herring authored
Replace of_get_address() and of_translate_address() calls with single call to of_address_to_resource(). Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by:
-
Lukas Bulwahn authored
Commit 1b00767f ("MIPS: Remove PMC MSP71xx platform") removes all uses of the config IRQ_MSP_CIC and IRQ_MSP_SLP. Remove these two obsolete configs IRQ_MSP_CIC and IRQ_MSP_SLP. Signed-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by:
-
- 17 Mar, 2023 5 commits
-
-
Lukas Bulwahn authored
Commit 85b9686d ("MIPS: ath79: drop platform device registration code") removes all files arch/mips/ath79/dev-*.[ch], adjusts the Makefile, but misses to adjust the Kconfig file. Hence, since then, the configs ATH79_DEV_* are really dead. Commit 3a77e0d7 ("MIPS: ath79: drop machfiles") already removes all configs that select ATH79_DEV_* config. So at that point, they was not a way to enable them with a kernel build configuration. Remove these obsolete ATH79_DEV_* configs. Signed-off-by:
-
Thomas Bogendoerfer authored
SIBYTE_BCM1125H is identical to SIBYTE_SB1250, so remove one of them. Signed-off-by: -
Thomas Bogendoerfer authored
Looks like these boards were nether in active use, so let's remove them. Signed-off-by: -
Thomas Bogendoerfer authored
SIBYTE_BCM1x55 is not selected anywhere, so let's get rid of it. Signed-off-by: -
Thomas Bogendoerfer authored
With the direct use of memblock interface board_mem_region is no longer needed. Signed-off-by:
-
- 14 Mar, 2023 20 commits
-
-
Rob Herring authored
It is preferred to use typed property access functions (i.e. of_property_read_<type> functions) rather than low-level of_get_property/of_find_property functions for reading properties. Convert reading boolean properties to to of_property_read_bool(). Signed-off-by:
-
Sergio Paracuellos authored
MT7620 SoCs have their own 'ralink_soc_info' structure with some information about the soc itself. In order to be able to retrieve this information from driver code and avoid architecture dependencies for retrieving these details introduce this 'soc_device'. Set 'data' pointer points to the struct 'ralink_soc_info' to be able to export also current soc information using this mechanism. We need to select 'SOC_BUS' in Kconfig configuration for these SoCs. Signed-off-by:
Sergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by:
-
Sergio Paracuellos authored
Move the SoC register value queries and tests to specific functions, to remove repetition of logic. No functional changes intended Signed-off-by:
-
Sergio Paracuellos authored
So that MT7620_SYSC_BASE can be used later in multiple functions without needing to repeat this __iomem declaration each time Signed-off-by:
-
Sergio Paracuellos authored
RT288X SoCs have their own 'ralink_soc_info' structure with some information about the soc itself. In order to be able to retrieve this information from driver code and avoid architecture dependencies for retrieving these details introduce this 'soc_device'. Set 'data' pointer points to the struct 'ralink_soc_info' to be able to export also current soc information using this mechanism. We need to select 'SOC_BUS' in Kconfig configuration for these SoCs. Signed-off-by:
-
Sergio Paracuellos authored
Move the SoC register value queries and tests to specific functions, to remove repetition of logic. No functional changes intended Signed-off-by:
-
Sergio Paracuellos authored
So that RT2880_SYSC_BASE can be used later in multiple functions without needing to repeat this __iomem declaration each time Signed-off-by:
-
Sergio Paracuellos authored
RT3883 SoC have its own 'ralink_soc_info' structure with some information about the soc itself. In order to be able to retrieve this information from driver code and avoid architecture dependencies for retrieving these details introduce this 'soc_device'. Set 'data' pointer points to the struct 'ralink_soc_info' to be able to export also current soc information using this mechanism. We need to select 'SOC_BUS' in Kconfig configuration for these SoCs. Signed-off-by:
-
Sergio Paracuellos authored
Move the SoC register value queries and tests to specific functions, to remove repetition of logic. No functional changes intended Signed-off-by:
-
Sergio Paracuellos authored
So that RT3883_SYSC_BASE can be used later in multiple functions without needing to repeat this __iomem declaration each time Signed-off-by:
-
Sergio Paracuellos authored
RT305x SoCs have their own 'ralink_soc_info' structure with some information about the soc itself. In order to be able to retrieve this information from driver code and avoid architecture dependencies for retrieving these details introduce this 'soc_device'. Set 'data' pointer points to the struct 'ralink_soc_info' to be able to export also current soc information using this mechanism. We need to select 'SOC_BUS' in Kconfig configuration for these SoCs. Signed-off-by:
-
Sergio Paracuellos authored
Move the SoC register value queries and tests to specific functions, to remove repetition of logic. No functional changes intended Signed-off-by:
-
Sergio Paracuellos authored
So that RT305X_SYSC_BASE can be used later in multiple functions without needing to repeat this __iomem declaration each time Signed-off-by:
-
Keguang Zhang authored
Add two Loongson-1 based boards: LSGZ 1B and Smartloong 1C. Signed-off-by:
Keguang Zhang <keguang.zhang@gmail.com> Reviewed-by:
-
Jiaxun Yang authored
It is clearly stated on "Loongson 3A3000/3B3000 processor user manual vol 2" that "All access requests using a non-cached algorithm are executed in a blocking order. That is, before the current read request data is returned to the processor, all subsequent requests are blocked and issued; All subsequent requests are blocked until the write request data has been sent or the issued write request has not received a write reply from the final receiver." Which means uncached read/write is strongly ordered. So we won't need this workaround. This option was introduced when we add initial support for GS464E, it looks like a misinterpretation of another section in the manual saying we need barriers to ensure MMIO order against DMA requests. Signed-off-by:
-
Jiaxun Yang authored
Q: Do we have really have write buffer A: Yes, on newer Loongson processors there is a "store fill buffer" that will collect *cached* writes, on all Loongson processors AXI crossbar will buffer all writes. Q: Then why do we want to remove CPU_HAS_WB? A: Because CPU_HAS_WB introduces wbflush, which intends to flush all write reuqests to mmio device. We won't be affected by store fill buffer because it won't buffer uncached writes. And a regular memory barrier is sufficient to flush crossbar write buffer. Signed-off-by:
-
Jiaxun Yang authored
Previously every write to SMP regisers are followed by nudge_writes, this incures a huge performance penalty because nudge_writes involves SYNC, which will be globalized on chip. Only set off nudge_writes when we really want other cores to see the result ASAP. Also replace read/write functions to relaxed version because we don't need extra barriers to protect against DMA. Signed-off-by:
-
Jiaxun Yang authored
wbflush here intends to let other cores see the results ASAP, nudge_writes fits this purpose better. Signed-off-by:
-
Jiaxun Yang authored
They are truely mmio pointers, so give them proper prefix. Signed-off-by:
-
Rafał Miłecki authored
It's a BCM5358 based home router. One of very few bcm47xx devices with cellular modems (here: LTE). Signed-off-by:
Rafał Miłecki <rafal@milecki.pl> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
- 12 Mar, 2023 4 commits
-
-
Linus Torvalds authored
-
Hector Martin authored
This reverts part of commit 015b8cc5 ("wifi: cfg80211: Fix use after free for wext") This commit broke WPA offload by unconditionally clearing the crypto modes for non-WEP connections. Drop that part of the patch. Signed-off-by:
Hector Martin <marcan@marcan.st> Reported-by:
Ilya <me@0upti.me> Reported-and-tested-by:
Janne Grunau <j@jannau.net> Reviewed-by:
Eric Curtin <ecurtin@redhat.com> Fixes: 015b8cc5 ("wifi: cfg80211: Fix use after free for wext") Cc: stable@kernel.org Link: https://lore.kernel.org/linux-wireless/ZAx0TWRBlGfv7pNl@kroah.com/T/#m11e6e0915ab8fa19ce8bc9695ab288c0fe018edfSigned-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmddLinus Torvalds authored
Pull tpm fixes from Jarkko Sakkinen: "Two additional bug fixes for v6.3" * tag 'tpm-v6.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd: tpm: disable hwrng for fTPM on some AMD designs tpm/eventlog: Don't abort tpm_read_log on faulty ACPI address
-
Mario Limonciello authored
AMD has issued an advisory indicating that having fTPM enabled in BIOS can cause "stuttering" in the OS. This issue has been fixed in newer versions of the fTPM firmware, but it's up to system designers to decide whether to distribute it. This issue has existed for a while, but is more prevalent starting with kernel 6.1 because commit b006c439 ("hwrng: core - start hwrng kthread also for untrusted sources") started to use the fTPM for hwrng by default. However, all uses of /dev/hwrng result in unacceptable stuttering. So, simply disable registration of the defective hwrng when detecting these faulty fTPM versions. As this is caused by faulty firmware, it is plausible that such a problem could also be reproduced by other TPM interactions, but this hasn't been shown by any user's testing or reports. It is hypothesized to be triggered more frequently by the use of the RNG because userspace software will fetch random numbers regularly. Intentionally continue to register other TPM functionality so that users that rely upon PCR measurements or any storage of data will still have access to it. If it's found later that another TPM functionality is exacerbating this problem a module parameter it can be turned off entirely and a module parameter can be introduced to allow users who rely upon fTPM functionality to turn it on even though this problem is present. Link: https://www.amd.com/en/support/kb/faq/pa-410 Link: https://bugzilla.kernel.org/show_bug.cgi?id=216989 Link: https://lore.kernel.org/all/20230209153120.261904-1-Jason@zx2c4.com/ Fixes: b006c439 ("hwrng: core - start hwrng kthread also for untrusted sources") Cc: stable@vger.kernel.org Cc: Jarkko Sakkinen <jarkko@kernel.org> Cc: Thorsten Leemhuis <regressions@leemhuis.info> Cc: James Bottomley <James.Bottomley@hansenpartnership.com> Tested-by: reach622@mailcuk.com Tested-by:
Bell <1138267643@qq.com> Co-developed-by:
Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
Mario Limonciello <mario.limonciello@amd.com> Reviewed-by:
Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
-
