Re: [PATCH] arm64: link with -z norelro regardless of CONFIG_RELOCATABLE
On Tue, 20 Oct 2020 at 22:16, Nick Desaulniers wrote:
>
> On Tue, Oct 20, 2020 at 10:57 AM Will Deacon wrote:
> >
> > On Fri, 16 Oct 2020 10:53:39 -0700, Nick Desaulniers wrote:
> > > With CONFIG_EXPERT=y, CONFIG_KASAN=y, CONFIG_RANDOMIZE_BASE=n,
> > > CONFIG_RELOCATABLE=n, we observe the following failure when trying to
> > > link the kernel image with LD=ld.lld:
> > >
> > > error: section: .exit.data is not contiguous with other relro sections
> > >
> > > ld.lld defaults to -z relro while ld.bfd defaults to -z norelro. This
> > > was previously fixed, but only for CONFIG_RELOCATABLE=y.
> >
> > Applied to arm64 (for-next/core), thanks!
> >
> > [1/1] arm64: link with -z norelro regardless of CONFIG_RELOCATABLE
> > https://git.kernel.org/arm64/c/3b92fa7485eb
>
> IF we wanted to go further and remove `-z norelro`, or even enable `-z
> relro` for aarch64, then we would have to detangle some KASAN/GCOV
> generated section discard spaghetti.
Why on earth would we want that?
> Fangrui did some more digging
> and found that .fini_array.* sections were relro (read only after
> relocations, IIUC), so adding them to EXIT_DATA
> (include/asm-generic/vmlinux.lds.h) was causing them to get included
> in .exit.data (arch/arm64/kernel/vmlinux.lds.S) making that relro.
> There's some history here with commits:
>
> - e41f501d39126 ("vmlinux.lds: account for destructor sections")
> - 8dcf86caa1e3da ("vmlinux.lds.h: Fix incomplete .text.exit discards")
> - d812db78288d7 ("vmlinux.lds.h: Avoid KASAN and KCSAN's unwanted sections")
>
> It seems the following works for quite a few different
> configs/toolchains I played with, but the big IF is whether enabling
> `-z relro` is worthwhile? If the kernel does respect that mapping,
> then I assume that's a yes, but I haven't checked yet whether relro is
> respected within the kernel (`grep -rn RELRO` turns up nothing
> interesting). I also haven't checked yet whether all supported
> versions of GNU ld.bfd support -z relro (guessing not, since a quick
> test warns: `aarch64-linux-gnu-ld: warning: -z relro ignored` for
> v2.34.90.20200706, may be holding it wrong).
>
RELRO just moves statically initialized const pointers into a separate
section so we can place it in a way that allows us to easily map it
r/w during load, and switch it over to r/o once the relocations have
been applied.
On AArch64, we don't even use -fpic to build the kernel, and load time
relocations may appear everywhere in .text, .rodata etc etc, which is
absolutely fine given that we apply the relocations way before we
finalize the kernel mappings. This means that, in our case, statically
initialized const pointers will be mapped r/o already, and we don't
need RELRO.
In general, we should ensure that the 'relocatable bare metal' case
doesn't get snowed under, as toolchain development is [understandably]
very focused on hosted binaries that use shared libraries, where
things like CoW footprint, ELF symbol preemption, text relocations and
RELRO sections actually matter. For bare metal, it is quite the
opposite: text relocations are fine, there is no CoW so minimizing the
footprint of the .so pages that are modified due to relocations is
unnecessary, and symbols cannot be preempted either. So many of the
shared library tricks actually make things worse for us, because we
have to work around them while they have no benefit for us.
I have suggested this before, but perhaps we should have a
-mcmodel=kernel (like x86 does) that takes these things into account?
As a start, it could imply -cmodel=small (which we rely on today), but
with guarantees that the generated code is position independent, but
without GOT indirections, and that the resulting object code can be
linked with -pie (so that we have access to the load time relocations
in the bare metal binary itself). This is something we rely on today,
and happens to work in practice, but this could easily break in the
future.
> (Fangrui also filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97507
> in regards to GCOV+GCC)
>
> diff --git a/include/asm-generic/vmlinux.lds.h
> b/include/asm-generic/vmlinux.lds.h
> index cd1bf600..64578c998e53 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -744,7 +744,6 @@
>
> #define EXIT_DATA \
> *(.exit.data .exit.data.*) \
> - *(.fini_array .fini_array.*)\
> *(.dtors .dtors.*) \
> MEM_DISCARD(exit.data*) \
> MEM_DISCARD(exit.rodata*)
> @@ -995,6 +994,7 @@
> #if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KCSAN)
> # ifdef CONFIG_CONSTRUCTORS
> # define SANITIZER_DISCARDS \
> + *(.fini_array .fini_array.*)\
> *(.eh_frame)
>
[PATCH] scsi: megaraid_sas: use spin_lock() in hard IRQ
Since we already in hard IRQ context when running megasas_isr(), so use
spin_lock() is enough, which is faster than spin_lock_irqsave().
Signed-off-by: Xianting Tian
---
drivers/scsi/megaraid/megaraid_sas_base.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 2b7e7b5f3..bd186254d 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -3977,15 +3977,14 @@ static irqreturn_t megasas_isr(int irq, void *devp)
{
struct megasas_irq_context *irq_context = devp;
struct megasas_instance *instance = irq_context->instance;
- unsigned long flags;
irqreturn_t rc;
if (atomic_read(&instance->fw_reset_no_pci_access))
return IRQ_HANDLED;
- spin_lock_irqsave(&instance->hba_lock, flags);
+ spin_lock(&instance->hba_lock);
rc = megasas_deplete_reply_queue(instance, DID_OK);
- spin_unlock_irqrestore(&instance->hba_lock, flags);
+ spin_unlock(&instance->hba_lock);
return rc;
}
--
2.17.1
[PULL REQUEST] i2c for 5.10
Linus, everyone, during this short break of my holidays, I send the first pull request of I2C for 5.10. Main changes: * if a host can be a client, too, the I2C core can now use it to emulate SMBus HostNotify support (STM32 and R-Car added this so far) * also for client mode, a testunit has been added. It can create rare situations on the bus, so host controllers can be tested * a binding has been added to mark the bus as "single-master". This allows for better timeout detections * new driver for Mellanox Bluefield * massive refactoring of the Tegra driver * EEPROMs recognized by the at24 driver can now have custom names * rest is driver updates Please pull. Thanks, Wolfram The following changes since commit d012a7190fc1fd72ed48911e77ca97ba4521bccd: Linux 5.9-rc2 (2020-08-23 14:08:43 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-5.10 for you to fetch changes up to 40daf09a30a0c86a038bcce606604333f32e03f8: Documentation: i2c: add testunit docs to index (2020-10-05 22:57:45 +0200) Alain Volmat (4): i2c: smbus: add core function handling SMBus host-notify i2c: stm32f7: Add SMBus Host-Notify protocol support i2c: stm32: name slave slot to ease maintenance i2c: stm32: fix error message on upon dma_request_chan & defer handling Andy Shevchenko (3): i2c: ismt: Describe parameters in kernel doc i2c: ismt: Add support for Intel Emmitsburg PCH i2c: nvidia-gpu: Use put_unaligned_be24() Anson Huang (1): i2c: imx: Use dev_err_probe() to simplify error handling Barry Song (1): i2c: busses: replace spin_lock_irqsave by spin_lock in hard IRQ Dirk Behme (1): i2c: rcar: Auto select RESET_CONTROLLER Dmitry Osipenko (32): i2c: tegra: Make tegra_i2c_flush_fifos() usable in atomic transfer i2c: tegra: Add missing pm_runtime_put() i2c: tegra: Handle potential error of tegra_i2c_flush_fifos() i2c: tegra: Mask interrupt in tegra_i2c_issue_bus_clear() i2c: tegra: Initialize div-clk rate unconditionally i2c: tegra: Remove i2c_dev.clk_divisor_non_hs_mode member i2c: tegra: Runtime PM always available on Tegra i2c: tegra: Remove error message used for devm_request_irq() failure i2c: tegra: Use reset_control_reset() i2c: tegra: Use devm_platform_get_and_ioremap_resource() i2c: tegra: Use platform_get_irq() i2c: tegra: Use clk-bulk helpers i2c: tegra: Move out all device-tree parsing into tegra_i2c_parse_dt() i2c: tegra: Clean up probe function i2c: tegra: Reorder location of functions in the code i2c: tegra: Clean up variable types i2c: tegra: Remove outdated barrier() i2c: tegra: Remove likely/unlikely from the code i2c: tegra: Remove redundant check in tegra_i2c_issue_bus_clear() i2c: tegra: Remove "dma" variable from tegra_i2c_xfer_msg() i2c: tegra: Rename wait/poll functions i2c: tegra: Factor out error recovery from tegra_i2c_xfer_msg() i2c: tegra: Factor out packet header setup from tegra_i2c_xfer_msg() i2c: tegra: Factor out register polling into separate function i2c: tegra: Factor out hardware initialization into separate function i2c: tegra: Check errors for both positive and negative values i2c: tegra: Improve formatting of variables i2c: tegra: Clean up variable names i2c: tegra: Clean up printk messages i2c: tegra: Clean up and improve comments i2c: tegra: Clean up whitespaces, newlines and indentation i2c: tegra: Improve driver module description Jaakko Laine (3): i2c: xiic: Change code alignment to 1 space only i2c: xiic: Improve struct memory alignment i2c: xiic: Support forcing single-master in DT Jarkko Nikula (2): i2c: Remove 'default n' from busses/Kconfig i2c: i801: Add support for Intel Alder Lake PCH-S Jean Delvare (2): eeprom: at24: Add support for the Sony VAIO EEPROMs eeprom: at24: Tidy at24_read() Jeffrey Lin (1): i2c: i801: Register lis3lv02d I2C device on Dell Latitude 5480 Jon Hunter (3): eeprom: at24: Initialise AT24 NVMEM ID field dt-bindings: eeprom: at24: Add label property for AT24 eeprom: at24: Support custom device names for AT24 EEPROMs Khalil Blaiech (2): dt-bindings: i2c: I2C binding for Mellanox BlueField SoC i2c: mlxbf: I2C SMBus driver for Mellanox BlueField SoC Krzysztof Kozlowski (10): i2c: mux: gpmux: Simplify with dev_err_probe() i2c: mux: reg: Simplify with dev_err_probe() i2c: bcm2835: Simplify with dev_err_probe() i2c: stm32: Simplify with dev_err_probe() i2c: rk3x: Simplify with dev_err_probe() i2c: imx: Fix external abort on interrupt in exit paths dt-bindings: i2c: imx-lpi2c: Add properties and use unevaluatedProperties dt-bindings: i2c: imx-l
Re: [PATCH v1 06/15] perf session: load data directory into tool process memory
Hi,
On Tue, Oct 13, 2020 at 8:30 PM Alexey Budankov
wrote:
> On 12.10.2020 19:49, Alexey Budankov wrote:
> > On 12.10.2020 19:09, Andi Kleen wrote:
> >> On Mon, Oct 12, 2020 at 11:58:58AM +0300, Alexey Budankov wrote:
> >>> diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
> >>> index 6afc670fdf0c..0752eec19813 100644
> >>> --- a/tools/perf/util/session.c
> >>> +++ b/tools/perf/util/session.c
> >>> @@ -2212,6 +2212,17 @@ reader__process_events(struct reader *rd, struct
> >>> perf_session *session,
> >>> goto more;
> >>>
> >>> out:
> >>> + if (rd->unmap_file) {
> >>> + int i;
> >>> +
> >>> + for (i = 0; i < NUM_MMAPS; i++) {
> >>> + if (mmaps[i]) {
> >>> + munmap(mmaps[i], mmap_size);
> >>> + mmaps[i] = NULL;
> >>
> >> Okay so where is the mmap? Would make more sense to put that
> >> into the same patch as who adds the mmap. Or is the mmap
> >> code already in the perf source? In that case it should
> >> probably be some common helper with the existing users.
> >
> > That mmap is already in the code. Agree, this part of the patch
> > can be applied prior the whole patch set.
>
> I take it back. Single trace file can't be unmapped yet since it also
> contains not only compressed records but also other records backing
> the data for aggregated analysis.
Are you talking about the auxtrace?
I thought everything will be compressed when it's enabled.
But if it's only for the auxtrace, maybe we can unmap them
with checking it as it's not the common case?
Thanks
Namhyung
Re: [RFC PATCH net-next 1/9] dt-bindings: net: dsa: convert ksz bindings document to yaml
On Mon Oct 19 2020, Christian Eggers wrote:
> Convert the bindings document for Microchip KSZ Series Ethernet switches
> from txt to yaml.
A few comments/questions below.
> diff --git a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
> b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
> new file mode 100644
> index ..f93c3bdd0b83
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
Currently the bindings don't have the company names in front of it.
> @@ -0,0 +1,147 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/dsa/microchip,ksz.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip KSZ Series Ethernet switches
> +
> +maintainers:
> + - Marek Vasut
> + - Woojung Huh
> +
> +properties:
> + # See Documentation/devicetree/bindings/net/dsa/dsa.yaml for a list of
> additional
> + # required and optional properties.
Don't you need to reference the dsa.yaml binding somehow?
> + compatible:
> +enum:
> + - "microchip,ksz8765"
> + - "microchip,ksz8794"
> + - "microchip,ksz8795"
> + - "microchip,ksz9477"
> + - "microchip,ksz9897"
> + - "microchip,ksz9896"
> + - "microchip,ksz9567"
> + - "microchip,ksz8565"
> + - "microchip,ksz9893"
> + - "microchip,ksz9563"
> + - "microchip,ksz8563"
> +
> + reset-gpios:
> +description:
> + Should be a gpio specifier for a reset line.
> +maxItems: 1
> +
> + microchip,synclko-125:
> +$ref: /schemas/types.yaml#/definitions/flag
> +description:
> + Set if the output SYNCLKO frequency should be set to 125MHz instead of
> 25MHz.
> +
> +required:
> + - compatible
> + - reg
> +
> +examples:
> + - |
> +#include
> +
> +// Ethernet switch connected via SPI to the host, CPU port wired to eth0:
> +eth0 {
> +fixed-link {
> +speed = <1000>;
> +full-duplex;
> +};
> +};
> +
> +spi0 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +pinctrl-0 = <&pinctrl_spi_ksz>;
> +cs-gpios = <&pioC 25 0>;
> +id = <1>;
> +
> +ksz9477: ksz9477@0 {
The node names should be switch. See dsa.yaml.
> +compatible = "microchip,ksz9477";
> +reg = <0>;
> +reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
> +
> +spi-max-frequency = <4400>;
> +spi-cpha;
> +spi-cpol;
> +
> +ports {
ethernet-ports are preferred.
Thanks,
Kurt
signature.asc
Description: PGP signature
Re: [RFT PATCH] arm64: dts: sdm845: Add iommus property to qup
Hi Bjorn, Steve,
On 20-10-20, 08:03, Bjorn Andersson wrote:
> From: Stephen Boyd
>
> The SMMU that sits in front of the QUP needs to be programmed properly
> so that the i2c geni driver can allocate DMA descriptors. Failure to do
> this leads to faults when using devices such as an i2c touchscreen where
> the transaction is larger than 32 bytes and we use a DMA buffer.
So I tried this and results in reboot for me when I use it in GSI
driver in RB3. I seem to already have the iommu properties [1] but values
are different
[1]:
https://git.linaro.org/people/vinod.koul/kernel.git/commit/?h=topic/gsi3-db&id=385edef08d55432a40fc9a8ae1f49248d5417a92
> arm-smmu 1500.iommu: Unexpected global fault, this could be serious
> arm-smmu 1500.iommu: GFSR 0x0002, GFSYNR0 0x0002, GFSYNR1
> 0x06c0, GFSYNR2 0x
>
> Add the right SID and mask so this works.
>
> Signed-off-by: Stephen Boyd
> [bjorn: Define for second QUP as well]
> Signed-off-by: Bjorn Andersson
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 8eb5a31346d2..7d635bc919cb 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -811,6 +811,7 @@ qupv3_id_0: geniqup@8c {
> clock-names = "m-ahb", "s-ahb";
> clocks = <&gcc GCC_QUPV3_WRAP_0_M_AHB_CLK>,
><&gcc GCC_QUPV3_WRAP_0_S_AHB_CLK>;
> + iommus = <&apps_smmu 0x0 0x3>;
> #address-cells = <2>;
> #size-cells = <2>;
> ranges;
> @@ -1119,6 +1120,7 @@ qupv3_id_1: geniqup@ac {
> clock-names = "m-ahb", "s-ahb";
> clocks = <&gcc GCC_QUPV3_WRAP_1_M_AHB_CLK>,
><&gcc GCC_QUPV3_WRAP_1_S_AHB_CLK>;
> + iommus = <&apps_smmu 0x6c0 0x3>;
> #address-cells = <2>;
> #size-cells = <2>;
> ranges;
> --
> 2.28.0
--
~Vinod
Re: [PATCH 2/2] dt: Remove booting-without-of.rst
Hi Rob, Em Thu, 8 Oct 2020 09:24:20 -0500 Rob Herring escreveu: > booting-without-of.rstt is an ancient document that first outlined > Flattened DeviceTree on PowerPC initially. The DT world has evolved a > lot in the 15 years since and booting-without-of.rst is pretty stale. > The name of the document itself is confusing if you don't understand the > evolution from real 'OpenFirmware'. Most of what booting-without-of.rst > contains is now in the DT specification (which evolved out of the > ePAPR). The few things that weren't documented in the DT specification > are now. > > All that remains is the boot entry details, so let's move these to arch > specific documents. The exception is arm which already has the same > details documented. Removing this document caused a warning at Documentation/arm/booting.rst: $ ./scripts/documentation-file-ref-check Documentation/arm/booting.rst: Documentation/devicetree/booting-without-of.rst as it mentions that the DTB format is described on booting-without-of.rst: 4b. Setup the device tree - The boot loader must load a device tree image (dtb) into system ram at a 64bit aligned address and initialize it with the boot data. The dtb format is documented in Documentation/devicetree/booting-without-of.rst. The kernel will look for the dtb magic value of 0xd00dfeed at the dtb physical address to determine if a dtb has been passed instead of a tagged list. So, I guess that such part of the document needs to be moved to booting.rst. Thanks, Mauro
[PATCH] arm64: defconfig: enable CONFIG_GPIO_MXC
From: Peng Fan To i.MX8MP, always met "Waiting for root device /dev/mmcblk1p2...", it is because the gpio driver not enabled. So enable CONFIG_GPIO_MXC to make sure it could boot well. Signed-off-by: Peng Fan --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 17a2df6a263e..5cfe3cf6f2ac 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -500,6 +500,7 @@ CONFIG_GPIO_ALTERA=m CONFIG_GPIO_DWAPB=y CONFIG_GPIO_MB86S7X=y CONFIG_GPIO_MPC8XXX=y +CONFIG_GPIO_MXC=y CONFIG_GPIO_PL061=y CONFIG_GPIO_RCAR=y CONFIG_GPIO_UNIPHIER=y -- 2.28.0
Re: [PATCH] firmware: gsmi: Drop the use of dma_pool_* API functions
On Wed, 21 Oct 2020 at 07:18, Greg Kroah-Hartman wrote: > > On Tue, Oct 20, 2020 at 10:01:41PM -0700, Furquan Shaikh wrote: > > GSMI driver uses dma_pool_* API functions for buffer allocation > > because it requires that the SMI buffers are allocated within 32-bit > > physical address space. However, this does not work well with IOMMU > > since there is no real device and hence no domain associated with the > > device. > > > > Since this is not a real device, it does not require any device > > address(IOVA) for the buffer allocations. The only requirement is to > > ensure that the physical address allocated to the buffer is within > > 32-bit physical address space. This change allocates a page using > > `get_zeroed_page()` and passes in GFP_DMA32 flag to ensure that the > > page allocation is done in the DMA32 zone. All the buffer allocation > > requests for gsmi_buf are then satisfed using this pre-allocated page > > for the device. > > Are you sure that "GFP_DMA32" really does what you think it does? A > "normal" call with GFP_KERNEL" will give you memory that is properly > dma-able. > > We should not be adding new GFP_DMA* users in the kernel in these days, > just call dma_alloc*() and you should be fine. > The point seems to be that this is not about DMA at all, and so there is no device associated with the DMA allocation. The other 'master' is the CPU running firmware in an execution mode where it can only access the bottom 4 GB of memory, and GFP_DMA32 happens to allocate from a zone which is guaranteed to be accessible to the firmware.
Re: arm64 build broken on linux next 20201021 - include/uapi/asm-generic/unistd.h:862:26: error: array index in initializer exceeds array bounds
Hi Naresh, On 21.10.2020 07:05, Naresh Kamboju wrote: > arm64 build broken while building linux next 20201021 tag. > > include/uapi/asm-generic/unistd.h:862:26: error: array index in > initializer exceeds array bounds > #define __NR_watch_mount 441 > ^ > > Reported-by: Naresh Kamboju Conflict resolution in commit 5394c6318b32f is incomplete. This fixes the build: diff --git a/arch/arm64/include/asm/unistd.h b/arch/arm64/include/asm/unistd.h index b3b2019f8d16..86a9d7b3eabe 100644 --- a/arch/arm64/include/asm/unistd.h +++ b/arch/arm64/include/asm/unistd.h @@ -38,7 +38,7 @@ #define __ARM_NR_compat_set_tls (__ARM_NR_COMPAT_BASE + 5) #define __ARM_NR_COMPAT_END (__ARM_NR_COMPAT_BASE + 0x800) -#define __NR_compat_syscalls 441 +#define __NR_compat_syscalls 442 #endif #define __ARCH_WANT_SYS_CLONE diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h index 094a685aa0f9..5df46517260e 100644 --- a/include/uapi/asm-generic/unistd.h +++ b/include/uapi/asm-generic/unistd.h @@ -863,7 +863,7 @@ __SYSCALL(__NR_process_madvise, sys_process_madvise) __SYSCALL(__NR_watch_mount, sys_watch_mount) #undef __NR_syscalls -#define __NR_syscalls 441 +#define __NR_syscalls 442 /* * 32 bit systems traditionally used different Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
Re: Segfault in pahole 1.18 when building kernel 5.9.1 for arm64
On 20. 10. 20, 14:20, Arnaldo Carvalho de Melo wrote: Yeah, I observe the very same. I reported it at: https://bugzilla.suse.com/show_bug.cgi?id=1177921 Would it be possible to try with https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?h=tmp.libbtf_encoder ? Yes, that branch fixes the crashes and the kernel build finishes. The zero-sized symbol error remains. So what should distributions do now -- should we switch to a pahole snapshot for a while? thanks, -- js
[PATCH v3] fat: Add KUnit tests for checksums and timestamps
Add some basic sanity-check tests for the fat_checksum() function and
the fat_time_unix2fat() and fat_time_fat2unix() functions. These unit
tests verify these functions return correct output for a number of test
inputs.
These tests were inspored by -- and serve a similar purpose to -- the
timestamp parsing KUnit tests in ext4[1].
Note that, unlike fat_time_unix2fat, fat_time_fat2unix wasn't previously
exported, so this patch exports it as well. This is required for the
case where we're building the fat and fat_test as modules.
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/ext4/inode-test.c
Signed-off-by: David Gow
Acked-by: OGAWA Hirofumi
---
Changes since v2:
https://lore.kernel.org/linux-kselftest/20201020055856.1270482-1-david...@google.com/
- Comment that the export for fat_time_fat2unix() function is for KUnit
tests.
Changes since v1:
https://lore.kernel.org/linux-kselftest/20201017064107.375174-1-david...@google.com/
- Now export fat_time_fat2unix() so that the test can access it when
built as a module.
Cheers,
-- David
fs/fat/Kconfig| 13 +++
fs/fat/Makefile | 2 +
fs/fat/fat_test.c | 196 ++
fs/fat/misc.c | 2 +
4 files changed, 213 insertions(+)
create mode 100644 fs/fat/fat_test.c
diff --git a/fs/fat/Kconfig b/fs/fat/Kconfig
index 66532a71e8fd..fdef03b79c69 100644
--- a/fs/fat/Kconfig
+++ b/fs/fat/Kconfig
@@ -115,3 +115,16 @@ config FAT_DEFAULT_UTF8
Say Y if you use UTF-8 encoding for file names, N otherwise.
See for more information.
+
+config FAT_KUNIT_TEST
+ tristate "Unit Tests for FAT filesystems" if !KUNIT_ALL_TESTS
+ select FAT_FS
+ depends on KUNIT
+ default KUNIT_ALL_TESTS
+ help
+ This builds the FAT KUnit tests
+
+ For more information on KUnit and unit tests in general, please refer
+ to the KUnit documentation in Documentation/dev-tools/kunit
+
+ If unsure, say N
diff --git a/fs/fat/Makefile b/fs/fat/Makefile
index 70645ce2f7fc..2b034112690d 100644
--- a/fs/fat/Makefile
+++ b/fs/fat/Makefile
@@ -10,3 +10,5 @@ obj-$(CONFIG_MSDOS_FS) += msdos.o
fat-y := cache.o dir.o fatent.o file.o inode.o misc.o nfs.o
vfat-y := namei_vfat.o
msdos-y := namei_msdos.o
+
+obj-$(CONFIG_FAT_KUNIT_TEST) += fat_test.o
diff --git a/fs/fat/fat_test.c b/fs/fat/fat_test.c
new file mode 100644
index ..c99bfbdf89bb
--- /dev/null
+++ b/fs/fat/fat_test.c
@@ -0,0 +1,196 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * KUnit tests for FAT filesystems.
+ *
+ * Copyright (C) 2020 Google LLC.
+ * Author: David Gow
+ */
+
+#include
+
+#include "fat.h"
+
+static void fat_checksum_test(struct kunit *test)
+{
+ /* With no extension. */
+ KUNIT_EXPECT_EQ(test, fat_checksum("VMLINUX"), 44);
+ /* With 3-letter extension. */
+ KUNIT_EXPECT_EQ(test, fat_checksum("README TXT"), 115);
+ /* With short (1-letter) extension. */
+ KUNIT_EXPECT_EQ(test, fat_checksum("ABCDEFGHA "), 98);
+}
+
+
+struct fat_timestamp_testcase {
+ const char *name;
+ struct timespec64 ts;
+ __le16 time;
+ __le16 date;
+ u8 cs;
+ int time_offset;
+};
+
+const static struct fat_timestamp_testcase time_test_cases[] = {
+ {
+ .name = "Earliest possible UTC (1980-01-01 00:00:00)",
+ .ts = {.tv_sec = 315532800LL, .tv_nsec = 0L},
+ .time = 0,
+ .date = 33,
+ .cs = 0,
+ .time_offset = 0,
+ },
+ {
+ .name = "Latest possible UTC (2107-12-31 23:59:58)",
+ .ts = {.tv_sec = 4354819198LL, .tv_nsec = 0L},
+ .time = 49021,
+ .date = 65439,
+ .cs = 0,
+ .time_offset = 0,
+ },
+ {
+ .name = "Earliest possible (UTC-11) (== 1979-12-31 13:00:00
UTC)",
+ .ts = {.tv_sec = 315493200LL, .tv_nsec = 0L},
+ .time = 0,
+ .date = 33,
+ .cs = 0,
+ .time_offset = 11 * 60,
+ },
+ {
+ .name = "Latest possible (UTC+11) (== 2108-01-01 10:59:58 UTC)",
+ .ts = {.tv_sec = 4354858798LL, .tv_nsec = 0L},
+ .time = 49021,
+ .date = 65439,
+ .cs = 0,
+ .time_offset = -11 * 60,
+ },
+ {
+ .name = "Leap Day / Year (1996-02-29 00:00:00)",
+ .ts = {.tv_sec = 825552000LL, .tv_nsec = 0L},
+ .time = 0,
+ .date = 8285,
+ .cs = 0,
+ .time_offset = 0,
+ },
+ {
+ .name = "Year 2000 is leap year (2000-02-29 00:00:00)",
+ .ts = {.tv_sec = 951782400LL, .tv_nsec = 0L},
+ .time = 0,
+ .date = 10333,
+ .cs = 0,
+ .time_offset = 0,
+ },
+ {
+ .name
Re: [f2fs-dev] [PATCH] f2fs: add compr_inode and compr_blocks sysfs nodes
On 2020/10/16 13:14, Daeho Jeong wrote:
From: Daeho Jeong
Added compr_inode to show compressed inode count and compr_blocks to
show compressed block count in sysfs.
As there are so many entries in ../f2fs// directory, it looks a mess
there, I suggest that we can add a new directory 'stats' in ../f2fs//,
in where we can store all readonly stats related entries there later.
How do you think?
Thanks,
Signed-off-by: Daeho Jeong
---
Documentation/ABI/testing/sysfs-fs-f2fs | 10 ++
fs/f2fs/sysfs.c | 17 +
2 files changed, 27 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs
b/Documentation/ABI/testing/sysfs-fs-f2fs
index 834d0becae6d..a01c26484c69 100644
--- a/Documentation/ABI/testing/sysfs-fs-f2fs
+++ b/Documentation/ABI/testing/sysfs-fs-f2fs
@@ -350,3 +350,13 @@ Date: April 2020
Contact: "Daeho Jeong"
Description: Give a way to change iostat_period time. 3secs by default.
The new iostat trace gives stats gap given the period.
+
+What: /sys/fs/f2fs//compr_inode
+Date: October 2020
+Contact: "Daeho Jeong"
+Description: Show compressed inode count
+
+What: /sys/fs/f2fs//compr_blocks
+Date: October 2020
+Contact: "Daeho Jeong"
+Description: Show compressed block count
diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c
index 94c98e412aa1..7139a29a00d3 100644
--- a/fs/f2fs/sysfs.c
+++ b/fs/f2fs/sysfs.c
@@ -223,6 +223,19 @@ static ssize_t avg_vblocks_show(struct f2fs_attr *a,
f2fs_update_sit_info(sbi);
return sprintf(buf, "%llu\n", (unsigned long long)(si->avg_vblocks));
}
+
+static ssize_t compr_inode_show(struct f2fs_attr *a,
+ struct f2fs_sb_info *sbi, char *buf)
+{
+ return sprintf(buf, "%u\n", atomic_read(&sbi->compr_inode));
+}
+
+static ssize_t compr_blocks_show(struct f2fs_attr *a,
+ struct f2fs_sb_info *sbi, char *buf)
+{
+ return sprintf(buf, "%llu\n", atomic64_read(&sbi->compr_blocks));
+}
+
#endif
static ssize_t main_blkaddr_show(struct f2fs_attr *a,
@@ -591,6 +604,8 @@ F2FS_STAT_ATTR(STAT_INFO, f2fs_stat_info,
gc_background_calls, bg_gc);
F2FS_GENERAL_RO_ATTR(moved_blocks_background);
F2FS_GENERAL_RO_ATTR(moved_blocks_foreground);
F2FS_GENERAL_RO_ATTR(avg_vblocks);
+F2FS_GENERAL_RO_ATTR(compr_inode);
+F2FS_GENERAL_RO_ATTR(compr_blocks);
#endif
#ifdef CONFIG_FS_ENCRYPTION
@@ -675,6 +690,8 @@ static struct attribute *f2fs_attrs[] = {
ATTR_LIST(moved_blocks_foreground),
ATTR_LIST(moved_blocks_background),
ATTR_LIST(avg_vblocks),
+ ATTR_LIST(compr_inode),
+ ATTR_LIST(compr_blocks),
#endif
NULL,
};
Re: block, bfq: lockdep circular locking dependency gripe
> Il giorno 20 ott 2020, alle ore 18:54, Jens Axboe ha
> scritto:
>
> On 10/20/20 1:15 AM, Paolo Valente wrote:
>>> Il giorno 20 ott 2020, alle ore 08:15, Mike Galbraith ha
>>> scritto:
>>>
>>> [ 1917.361401] ==
>>> [ 1917.361406] WARNING: possible circular locking dependency detected
>>> [ 1917.361413] 5.9.0.g7cf726a-master #2 Tainted: G S E
>>> [ 1917.361417] --
>>> [ 1917.361422] kworker/u16:35/15995 is trying to acquire lock:
>>> [ 1917.361428] 89232237f7e0 (&ioc->lock){..-.}-{2:2}, at:
>>> put_io_context+0x30/0x90
>>> [ 1917.361440]
>>> but task is already holding lock:
>>> [ 1917.361445] 892244d2cc08 (&bfqd->lock){-.-.}-{2:2}, at:
>>> bfq_insert_requests+0x89/0x680
>>> [ 1917.361456]
>>> which lock already depends on the new lock.
>>>
>>> [ 1917.361463]
>>> the existing dependency chain (in reverse order) is:
>>> [ 1917.361469]
>>> -> #1 (&bfqd->lock){-.-.}-{2:2}:
>>> [ 1917.361479]_raw_spin_lock_irqsave+0x3d/0x50
>>> [ 1917.361484]bfq_exit_icq_bfqq+0x48/0x3f0
>>> [ 1917.361489]bfq_exit_icq+0x13/0x20
>>> [ 1917.361494]put_io_context_active+0x55/0x80
>>> [ 1917.361499]do_exit+0x72c/0xca0
>>> [ 1917.361504]do_group_exit+0x47/0xb0
>>> [ 1917.361508]__x64_sys_exit_group+0x14/0x20
>>> [ 1917.361513]do_syscall_64+0x33/0x40
>>> [ 1917.361518]entry_SYSCALL_64_after_hwframe+0x44/0xa9
>>> [ 1917.361523]
>>> -> #0 (&ioc->lock){..-.}-{2:2}:
>>> [ 1917.361532]__lock_acquire+0x149d/0x1a70
>>> [ 1917.361537]lock_acquire+0x1a7/0x3b0
>>> [ 1917.361542]_raw_spin_lock_irqsave+0x3d/0x50
>>> [ 1917.361547]put_io_context+0x30/0x90
>>> [ 1917.361552]blk_mq_free_request+0x4f/0x140
>>> [ 1917.361557]blk_attempt_req_merge+0x19/0x30
>>> [ 1917.361563]elv_attempt_insert_merge+0x4f/0x90
>>> [ 1917.361568]blk_mq_sched_try_insert_merge+0x28/0x40
>>> [ 1917.361574]bfq_insert_requests+0x94/0x680
>>> [ 1917.361579]blk_mq_sched_insert_requests+0xd1/0x2a0
>>> [ 1917.361584]blk_mq_flush_plug_list+0x12d/0x240
>>> [ 1917.361589]blk_flush_plug_list+0xb4/0xd0
>>> [ 1917.361594]io_schedule_prepare+0x3c/0x40
>>> [ 1917.361599]io_schedule+0xb/0x40
>>> [ 1917.361604]blk_mq_get_tag+0x13a/0x250
>>> [ 1917.361608]__blk_mq_alloc_request+0x5c/0x130
>>> [ 1917.361613]blk_mq_submit_bio+0xf3/0x770
>>> [ 1917.361618]submit_bio_noacct+0x41e/0x4b0
>>> [ 1917.361622]submit_bio+0x33/0x160
>>> [ 1917.361644]ext4_io_submit+0x49/0x60 [ext4]
>>> [ 1917.361661]ext4_writepages+0x683/0x1070 [ext4]
>>> [ 1917.361667]do_writepages+0x3c/0xe0
>>> [ 1917.361672]__writeback_single_inode+0x62/0x630
>>> [ 1917.361677]writeback_sb_inodes+0x218/0x4d0
>>> [ 1917.361681]__writeback_inodes_wb+0x5f/0xc0
>>> [ 1917.361686]wb_writeback+0x283/0x490
>>> [ 1917.361691]wb_workfn+0x29a/0x670
>>> [ 1917.361696]process_one_work+0x283/0x620
>>> [ 1917.361701]worker_thread+0x39/0x3f0
>>> [ 1917.361706]kthread+0x152/0x170
>>> [ 1917.361711]ret_from_fork+0x1f/0x30
>>> [ 1917.361715]
>>> other info that might help us debug this:
>>>
>>> [ 1917.361722] Possible unsafe locking scenario:
>>>
>>> [ 1917.361728]CPU0CPU1
>>> [ 1917.361731]
>>> [ 1917.361736] lock(&bfqd->lock);
>>> [ 1917.361740]lock(&ioc->lock);
>>> [ 1917.361746]lock(&bfqd->lock);
>>> [ 1917.361752] lock(&ioc->lock);
>>> [ 1917.361757]
>>> *** DEADLOCK ***
>>>
>>> [ 1917.361763] 5 locks held by kworker/u16:35/15995:
>>> [ 1917.361767] #0: 892240c9bd38
>>> ((wq_completion)writeback){+.+.}-{0:0}, at: process_one_work+0x1fa/0x620
>>> [ 1917.361778] #1: 94569342fe78
>>> ((work_completion)(&(&wb->dwork)->work)){+.+.}-{0:0}, at:
>>> process_one_work+0x1fa/0x620
>>> [ 1917.361789] #2: 8921424ae0e0 (&type->s_umount_key#39){}-{3:3},
>>> at: trylock_super+0x16/0x50
>>> [ 1917.361800] #3: 8921424aaa40
>>> (&sbi->s_writepages_rwsem){.+.+}-{0:0}, at: do_writepages+0x3c/0xe0
>>> [ 1917.361811] #4: 892244d2cc08 (&bfqd->lock){-.-.}-{2:2}, at:
>>> bfq_insert_requests+0x89/0x680
>>> [ 1917.361821]
>>> stack backtrace:
>>> [ 1917.361827] CPU: 6 PID: 15995 Comm: kworker/u16:35 Kdump: loaded
>>> Tainted: G S E 5.9.0.g7cf726a-master #2
>>> [ 1917.361833] Hardware name: MEDION MS-7848/MS-7848, BIOS M7848W08.20C
>>> 09/23/2013
>>> [ 1917.361840] Workqueue: writeback wb_workfn (flush-8:32)
>>> [ 1917.361846] Call Trace:
>>> [ 1917.361854] dump_stack+0x77/0x97
>>> [ 1917.361860] check_noncircular+0xe7/0x100
>>> [ 1917.36186
Re: [PATCH v2 5/5] scsi: ufs: fix clkgating on/off correctly
On 2020-10-21 12:52, jaeg...@kernel.org wrote: On 10/21, Can Guo wrote: On 2020-10-21 03:52, Jaegeuk Kim wrote: > The below call stack prevents clk_gating at every IO completion. > We can remove the condition, ufshcd_any_tag_in_use(), since > clkgating_work > will check it again. > I think checking ufshcd_any_tag_in_use() in either ufshcd_release() or gate_work() can break UFS clk gating's functionality. ufshcd_any_tag_in_use() was introduced to replace hba->lrb_in_use. However, they are not exactly same - ufshcd_any_tag_in_use() returns true if any tag assigned from block layer is still in use, but tags are released asynchronously (through block softirq), meaning it does not reflect the real occupation of UFS host. That is after UFS host finishes all tasks, ufshcd_any_tag_in_use() can still return true. This change only removes the check of ufshcd_any_tag_in_use() in ufshcd_release(), but having the check of it in gate_work() can still prevent gating from happening. The current change works for you maybe because the tags are release before hba->clk_gating.delay_ms expires, but if hba->clk_gating.delay_ms is shorter or somehow block softirq is retarded, gate_work() may have chance to see ufshcd_any_tag_in_use() returns true. What do you think? I don't think this breaks clkgating, but fix the wrong condition check which prevented gate_work at all. As you mentioned, even if this schedules gate_work by racy conditions, gate_work will handle it as a last resort. If clocks cannot be gated after the last task is cleared from UFS host, then clk gating is broken, no? Assume UFS has completed the last task in its queue, as this change says, ufshcd_any_tag_in_use() is preventing ufshcd_release() from invoking gate_work(). Similarly, ufshcd_any_tag_in_use() can prevent gate_work() from doing its real work - disabling the clocks. Do you agree? if (hba->clk_gating.active_reqs || hba->ufshcd_state != UFSHCD_STATE_OPERATIONAL || ufshcd_any_tag_in_use(hba) || hba->outstanding_tasks || hba->active_uic_cmd || hba->uic_async_done) goto rel_lock; Thanks, Can Guo. Thanks, Can Guo. In __ufshcd_transfer_req_compl Ihba->lrb_in_use is cleared immediately when UFS driver finishes all tasks > ufshcd_complete_requests(struct ufs_hba *hba) > ufshcd_transfer_req_compl() > __ufshcd_transfer_req_compl() > __ufshcd_release(hba) > if (ufshcd_any_tag_in_use() == 1) >return; > ufshcd_tmc_handler(hba); > blk_mq_tagset_busy_iter(); > > Cc: Alim Akhtar > Cc: Avri Altman > Cc: Can Guo > Signed-off-by: Jaegeuk Kim > --- > drivers/scsi/ufs/ufshcd.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c > index b5ca0effe636..cecbd4ace8b4 100644 > --- a/drivers/scsi/ufs/ufshcd.c > +++ b/drivers/scsi/ufs/ufshcd.c > @@ -1746,7 +1746,7 @@ static void __ufshcd_release(struct ufs_hba *hba) > >if (hba->clk_gating.active_reqs || hba->clk_gating.is_suspended || >hba->ufshcd_state != UFSHCD_STATE_OPERATIONAL || > - ufshcd_any_tag_in_use(hba) || hba->outstanding_tasks || > + hba->outstanding_tasks || >hba->active_uic_cmd || hba->uic_async_done) >return;
Re: [PATCH] mailbox: qcom: Support building QCOM IPCC driver as module
Hi,
Please CC the driver maintainer(s) for relevant patches. For this driver,
I've been listed as the maintainer in the MAINTAINERS file.
On Wed, Oct 21, 2020 at 10:15:52AM +0800, Huang Yiwei wrote:
> Change CONFIG_QCOM_IPCC to tristate and add exit function to
> support module build for QCOM IPCC driver.
>
This is not going to work, sorry! There was a reason to make this driver
built-in in the first place. This driver registers itself as an irqchip and
provides interrupts to be consumed by the client drivers. So if we want to
unload the driver, then we should make sure to dispose all irqs consumed by
the client drivers and that's not possible currently. If you look into other
irqchip drivers, they're all made as built-in.
Thanks,
Mani
> Signed-off-by: Huang Yiwei
> ---
> drivers/mailbox/Kconfig | 2 +-
> drivers/mailbox/qcom-ipcc.c | 6 ++
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> index 05b1009..78f3006 100644
> --- a/drivers/mailbox/Kconfig
> +++ b/drivers/mailbox/Kconfig
> @@ -245,7 +245,7 @@ config SPRD_MBOX
> you want to build the Spreatrum mailbox controller driver.
>
> config QCOM_IPCC
> - bool "Qualcomm Technologies, Inc. IPCC driver"
> + tristate "Qualcomm Technologies, Inc. IPCC driver"
> depends on ARCH_QCOM || COMPILE_TEST
> help
> Qualcomm Technologies, Inc. Inter-Processor Communication Controller
> diff --git a/drivers/mailbox/qcom-ipcc.c b/drivers/mailbox/qcom-ipcc.c
> index 2d13c72..1ed9a87 100644
> --- a/drivers/mailbox/qcom-ipcc.c
> +++ b/drivers/mailbox/qcom-ipcc.c
> @@ -280,6 +280,12 @@ static int __init qcom_ipcc_init(void)
> }
> arch_initcall(qcom_ipcc_init);
>
> +static __exit void qcom_ipcc_exit(void)
> +{
> + platform_driver_unregister(&qcom_ipcc_driver);
> +}
> +module_exit(qcom_ipcc_exit);
> +
> MODULE_AUTHOR("Venkata Narendra Kumar Gutta ");
> MODULE_AUTHOR("Manivannan Sadhasivam ");
> MODULE_DESCRIPTION("Qualcomm Technologies, Inc. IPCC driver");
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
Re: arm64 build broken on linux next 20201021 - include/uapi/asm-generic/unistd.h:862:26: error: array index in initializer exceeds array bounds
Hi Naresh, On Wed, 21 Oct 2020 10:35:10 +0530 Naresh Kamboju wrote: > > arm64 build broken while building linux next 20201021 tag. > > include/uapi/asm-generic/unistd.h:862:26: error: array index in > initializer exceeds array bounds > #define __NR_watch_mount 441 Yeah, the __NR_syscalls in include/uapi/asm-generic/unistd.h needed to be fixed up in the notifications tree merge to be 442. Sorry about that, I will use the correct merge resolution tomorrow. -- Cheers, Stephen Rothwell pgpyidW4vGuHm.pgp Description: OpenPGP digital signature
Re: Segfault in pahole 1.18 when building kernel 5.9.1 for arm64
On 20. 10. 20, 19:15, Andrii Nakryiko wrote: On Tue, Oct 20, 2020 at 3:51 AM Jiri Slaby wrote: Hi, On 19. 10. 20, 1:18, Érico Rolim wrote: I'm trying to build kernel 5.9.1 for arm64, and my dotconfig has `CONFIG_DEBUG_INFO_BTF=y`, which requires pahole for building. However, pahole version 1.18 segfaults during the build, as can be seen below: PAHOLE: Error: Found symbol of zero size when encoding btf (sym: '__kvm_nvhe_arm64_ssbd_callback_required', cu: 'arch/arm64/kernel/cpu_errata.c'). The symbol is an alias coming from arch/arm64/kernel/vmlinux.lds: __kvm_nvhe_arm64_ssbd_callback_required = arm64_ssbd_callback_required;; What's readelf's output for that symbol? If it's legal for SST_OBJECT to have size zero, then we should just skip those in pahole. But it shouldn't crash in either case, of course. But as Arnaldo mentioned, that code changed significantly recently, so please check with latest pahole from tmp.libbtf_encoder branch. ... Yeah, I observe the very same. I reported it at: https://bugzilla.suse.com/show_bug.cgi?id=1177921 If you looked here, you would see: > $ readelf -Ws vml |grep arm64_ssbd_callback_re > 154271: 80001133e000 0 OBJECT GLOBAL DEFAULT 22 __kvm_nvhe_arm64_ssbd_callback_required > 159609: 80001133e000 8 OBJECT WEAK DEFAULT 22 arm64_ssbd_callback_required Yes, its zero-sized. And yes, the error happens even with tmp.libbtf_encoder, but pahole doesn't crash and the build finishes fine. thanks, -- js
Re: [Regression] "tpm: Require that all digests are present in TCG_PCR_EVENT2 structures" causes null pointer dereference
On 2020-10-20 17:07:50, Mimi Zohar wrote: > On Tue, 2020-09-29 at 13:52 -0400, Mimi Zohar wrote: > > On Mon, 2020-09-28 at 22:16 +0800, Kai-Heng Feng wrote: > > > Hi Jarkko, > > > > > > > On Sep 28, 2020, at 22:06, Jarkko Sakkinen > > > > wrote: > > > > > > > > On Mon, Sep 28, 2020 at 08:31:04PM +0800, Kai-Heng Feng wrote: > > > >> Commit 7f3d176f5f7e "tpm: Require that all digests are present in > > > >> TCG_PCR_EVENT2 structures" causes a null pointer dereference on all > > > >> laptops I have: > > > > > > > > ... > > > > > > > >> [ 17.868849] BUG: kernel NULL pointer dereference, address: > > > >> 002c > > > >> [ 17.868852] #PF: supervisor read access in kernel mode > > > >> [ 17.868854] #PF: error_code(0x) - not-present page > > > >> [ 17.868855] PGD 0 P4D 0 > > > >> [ 17.868858] Oops: [#1] SMP PTI > > > >> [ 17.868860] CPU: 0 PID: 1873 Comm: fwupd Not tainted 5.8.0-rc6+ #25 > > > >> [ 17.868861] Hardware name: LENOVO 20LAZ3TXCN/20LAZ3TXCN, BIOS > > > >> N27ET38W (1.24 ) 11/28/2019 > > > >> [ 17.868866] RIP: 0010:tpm2_bios_measurements_start+0x38/0x1f0 > > > >> [ 17.868868] Code: 55 41 54 53 48 83 ec 30 4c 8b 16 65 48 8b 04 25 > > > >> 28 00 00 00 48 89 45 d0 48 8b 47 70 4c 8b a0 d0 06 00 00 48 8b 88 d8 > > > >> 06 00 00 <41> 8b 5c 24 1c 48 89 4d b0 48 89 d8 48 83 c3 20 4d 85 d2 75 > > > >> 31 4c > > > >> [ 17.868869] RSP: 0018:9da500a9fde0 EFLAGS: 00010282 > > > >> [ 17.868871] RAX: 917d03dc4000 RBX: RCX: > > > >> 0010 > > > >> [ 17.868872] RDX: 1000 RSI: 917c99b19460 RDI: > > > >> 917c99b19438 > > > >> [ 17.868873] RBP: 9da500a9fe38 R08: bda4ffa33fc0 R09: > > > >> 917cbfeae4c0 > > > >> [ 17.868874] R10: R11: 0002 R12: > > > >> 0010 > > > >> [ 17.868875] R13: 917c99b19438 R14: 917c99b19460 R15: > > > >> 917c99b19470 > > > >> [ 17.868876] FS: 7f9d80988b00() GS:917d0740() > > > >> knlGS: > > > >> [ 17.868877] CS: 0010 DS: ES: CR0: 80050033 > > > >> [ 17.868878] CR2: 002c CR3: 000219b12004 CR4: > > > >> 003606f0 > > > >> [ 17.868879] Call Trace: > > > >> [ 17.868884] seq_read+0x95/0x470 > > > >> [ 17.868887] ? security_file_permission+0x150/0x160 > > > >> [ 17.868889] vfs_read+0xaa/0x190 > > > >> [ 17.868891] ksys_read+0x67/0xe0 > > > >> [ 17.868893] __x64_sys_read+0x1a/0x20 > > > >> [ 17.868896] do_syscall_64+0x52/0xc0 > > > >> [ 17.868898] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > >> [ 17.868900] RIP: 0033:0x7f9d83be91dc > > > >> [ 17.868901] Code: Bad RIP value. > > > >> [ 17.868902] RSP: 002b:7fff7f5e0250 EFLAGS: 0246 ORIG_RAX: > > > >> > > > >> [ 17.868903] RAX: ffda RBX: 5651d262f420 RCX: > > > >> 7f9d83be91dc > > > >> [ 17.868904] RDX: 1000 RSI: 7fff7f5e0350 RDI: > > > >> 0010 > > > >> [ 17.868905] RBP: 7f9d83cc54a0 R08: R09: > > > >> 5651d26c1830 > > > >> [ 17.868906] R10: 5651d2582010 R11: 0246 R12: > > > >> 1000 > > > >> [ 17.868907] R13: 7fff7f5e0350 R14: 0d68 R15: > > > >> 7f9d83cc48a0 > > > >> [ 17.868909] Modules linked in: rfcomm ccm cmac algif_hash > > > >> algif_skcipher af_alg snd_hda_codec_hdmi snd_hda_codec_realtek > > > >> snd_hda_codec_generic bnep joydev mei_hdcp wmi_bmof intel_rapl_msr > > > >> intel_wmi_thunderbolt x86_pkg_temp_thermal intel_powerclamp coretemp > > > >> nls_iso8859_1 kvm_intel kvm crct10dif_pclmul crc32_pclmul > > > >> ghash_clmulni_intel aesni_intel glue_helper crypto_simd cryptd rapl > > > >> input_leds intel_cstate snd_hda_intel snd_intel_dspcfg rmi_smbus > > > >> iwlmvm snd_hda_codec serio_raw snd_hwdep mac80211 rmi_core > > > >> snd_hda_core libarc4 uvcvideo snd_pcm videobuf2_vmalloc btusb > > > >> videobuf2_memops iwlwifi videobuf2_v4l2 btrtl btbcm videobuf2_common > > > >> btintel thunderbolt i915 bluetooth mei_me videodev thinkpad_acpi nvram > > > >> cfg80211 ledtrig_audio mei mc ecdh_generic ecc i2c_algo_bit > > > >> processor_thermal_device snd_seq_midi drm_kms_helper > > > >> snd_seq_midi_event intel_soc_dts_iosf syscopyarea sysfillrect > > > >> snd_rawmidi intel_pch_thermal sysimgblt intel_rapl_common > > > >> intel_xhci_usb_role_switch fb_sys_fops > u > > cs > > > i_acpi r > > > o > > > > les cec > > > >> [ 17.868935] typec_ucsi typec nxp_nci_i2c snd_seq nxp_nci wmi nci > > > >> nfc snd_timer snd_seq_device snd int3403_thermal soundcore > > > >> int340x_thermal_zone video mac_hid int3400_thermal acpi_pad > > > >> acpi_thermal_rel sch_fq_codel parport_pc ppdev lp parport drm > > > >> ip_tables x_tables autofs4 btrfs blake2b_generic libcrc32c xor > > > >> zstd_compress raid6_pq uas usb_storage psmouse e1000e nvme i2c_i801 > > > >> i2c_smbus nvme_core intel_
Re: [PATCH v7 1/4] KEYS: trusted: Add generic trusted keys framework
Thanks Mimi for your comments.
On Wed, 21 Oct 2020 at 08:51, Mimi Zohar wrote:
>
> On Wed, 2020-10-07 at 15:37 +0530, Sumit Garg wrote:
>
> > +/*
> > + * trusted_destroy - clear and free the key's payload
> > + */
> > +static void trusted_destroy(struct key *key)
> > +{
> > + kfree_sensitive(key->payload.data[0]);
> > +}
> > +
> > +struct key_type key_type_trusted = {
> > + .name = "trusted",
> > + .instantiate = trusted_instantiate,
> > + .update = trusted_update,
> > + .destroy = trusted_destroy,
> > + .describe = user_describe,
> > + .read = trusted_read,
> > +};
> > +EXPORT_SYMBOL_GPL(key_type_trusted);
> > +
> > +static int __init init_trusted(void)
> > +{
> > + int i, ret = 0;
> > +
> > + for (i = 0; i < ARRAY_SIZE(trusted_key_sources); i++) {
> > + if (trusted_key_source &&
> > + strncmp(trusted_key_source, trusted_key_sources[i].name,
> > + strlen(trusted_key_sources[i].name)))
> > + continue;
> > +
> > + trusted_key_ops = trusted_key_sources[i].ops;
> > +
> > + ret = trusted_key_ops->init();
> > + if (!ret)
> > + break;
> > + }
>
> In the case when the module paramater isn't specified and both TPM and
> TEE are enabled, trusted_key_ops is set to the last source initialized.
I guess there is some misunderstanding. Here it's only a single trust
source (TPM *or* TEE) is initialized and only that trust source would
be active at runtime. And trusted_key_ops would be initialized to the
first trust source whose initialization is successful (see check: "if
(!ret)").
> After patch 2/4, the last trusted source initialized is TEE. If the
> intention is to limit it to either TPM or TEE, then trusted_key_ops
> should have a default value, which could be overwritten at runtime.
> That would address Luke Hind's concerns of making the decision at
> compile time.
I think traversing the trust source list with the initial value being
TPM would be default value.
>
> trusted_key_ops should be defined as __ro_after_init, like is currently
> done for other LSM structures.
Sure, will do.
>
> > +
> > + /*
> > + * encrypted_keys.ko depends on successful load of this module even if
> > + * trusted key implementation is not found.
> > + */
> > + if (ret == -ENODEV)
> > + return 0;
> > +
> > + return ret;
> > +}
> > +
> > +static void __exit cleanup_trusted(void)
> > +{
> > + trusted_key_ops->exit();
>
> If the intention is really to support both TPM and TEE trusted keys at
> the same time, as James suggested, then the same "for" loop as in
> init_trusted() is needed here and probably elsewhere.
Current intention is to only support a single trust source (TPM or
TEE) at runtime. But in future if there are use-cases then framework
can be extended to support multiple trust sources at runtime as well.
-Sumit
>
> thanks,
>
> Mimi
>
Re: [PATCH 2/2] ARM: dts: tacoma: Add reserved memory for ramoops
On Wed, 21 Oct 2020, at 15:35, Joel Stanley wrote:
> On Fri, 16 Oct 2020 at 04:36, Andrew Jeffery wrote:
> >
> > Reserve a 1.5MiB region of memory to record kmsg dumps, console and
> > userspace message state into 16kiB ring-buffer slots. The sizing allows
> > for up to 32 dumps to be captured and read out.
> >
> > Set max-reason to KMSG_DUMP_EMERG to capture bad-path reboots.
> >
> > Signed-off-by: Andrew Jeffery
> > ---
> > arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts
> > b/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts
> > index 46f2f538baba..4f7e9b490e1a 100644
> > --- a/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts
> > +++ b/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts
> > @@ -26,6 +26,15 @@ reserved-memory {
> > #size-cells = <1>;
> > ranges;
> >
> > + ramoops@b9e8 {
> > + compatible = "ramoops";
> > + reg = <0xb9e8 0x18>;
>
> I take that r-b back. When booting, we see:
>
> [0.00] region@ba00 (0xb800--0xbc00) overlaps with
> ramoops@b9e8 (0xb9e8--0xba00)
>
> Which appears to be a true statement.
Yep:
>
> > + record-size = <0x4000>;
> > + console-size = <0x4000>;
> > + pmsg-size = <0x4000>;
> > + max-reason = <3>; /* KMSG_DUMP_EMERG */
> > + };
> > +
> > flash_memory: region@ba00 {
> > no-map;
> > reg = <0xb800 0x400>; /* 64M */
Looks like I derived the ramoops address from the flash_memory node label, but
that's mismatched with its reg value.
[PATCH] btrfs: ref-verify: Fix memleak in btrfs_ref_tree_mod
There is one error handling path does not free ref, which may cause a memory leak. Signed-off-by: Dinghao Liu --- fs/btrfs/ref-verify.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/btrfs/ref-verify.c b/fs/btrfs/ref-verify.c index 7f03dbe5b609..78693d3dd15b 100644 --- a/fs/btrfs/ref-verify.c +++ b/fs/btrfs/ref-verify.c @@ -860,6 +860,7 @@ int btrfs_ref_tree_mod(struct btrfs_fs_info *fs_info, "dropping a ref for a root that doesn't have a ref on the block"); dump_block_entry(fs_info, be); dump_ref_action(fs_info, ra); + kfree(ref); kfree(ra); goto out_unlock; } -- 2.17.1
RE: [PATCH V4 0/6] can: flexcan: add stop mode support for i.MX8QM
> -Original Message- > From: Joakim Zhang > Sent: 2020年10月21日 13:25 > To: m...@pengutronix.de; robh...@kernel.org; shawn...@kernel.org; > s.ha...@pengutronix.de > Cc: ker...@pengutronix.de; dl-linux-imx ; Ying Liu > ; linux-...@vger.kernel.org; net...@vger.kernel.org; > linux-kernel@vger.kernel.org > Subject: [PATCH V4 0/6] can: flexcan: add stop mode support for i.MX8QM > > The first patch from Liu Ying aims to export SCU symbols for SoCs w/wo SCU, so > that no need to check CONFIG_IMX_SCU in the specific driver. > > The following patches are flexcan fixes and add stop mode support for > i.MX8QM. Hi Shawnguo, Could you please help review patch 1/6 and 5/6? Since flexcan driver depends on these. Thanks. For patch 1/6, it will benefit other drivers which cover SoCs w/wo SCU, such as i.MX Ethernet Controller driver (drivers/net/ethernet/freescale/fec_main.c). Best Regards, Joakim Zhang
Re: WARNING in md_ioctl
On Mon, Oct 19, 2020 at 12:03 AM Dae R. Jeong wrote:
>
> > diff --git i/drivers/md/md.c w/drivers/md/md.c
> > index 6072782070230..49442a3f4605b 100644
> > --- i/drivers/md/md.c
> > +++ w/drivers/md/md.c
> > @@ -7591,8 +7591,10 @@ static int md_ioctl(struct block_device *bdev,
> > fmode_t mode,
> > err = -EBUSY;
> > goto out;
> > }
> > - WARN_ON_ONCE(test_bit(MD_CLOSING, &mddev->flags));
> > - set_bit(MD_CLOSING, &mddev->flags);
> > + if (test_and_set_bit(MD_CLOSING, &mddev->flags)) {
> > + err = -EBUSY;
> > + goto out;
> > + }
> > did_set_md_closing = true;
> > mutex_unlock(&mddev->open_mutex);
> > sync_blockdev(bdev);
> >
> > Could you please test whether this fixes the issue?
>
> Since &mddev->open_mutex is held when testing a bit of mddev->flags, I
> modified the code just a little bit by putting mutex_unlock() as
> belows.
Good catch! The fix looks good. Would you like to submit a patch for it?
Thanks,
Song
Re: [PATCH v2 1/4] block: keyslot-manager: Introduce passthrough keyslot manager
On Tue, Oct 20, 2020 at 09:44:23PM -0700, Eric Biggers wrote: > On Fri, Oct 16, 2020 at 08:20:44AM +0100, Christoph Hellwig wrote: > > And this just validates my argument that calling the inline crypto work > > directly from the block layer instead of just down below in blk-mq was > > wrong. We should not require any support from stacking drivers at the > > keyslot manager level. > > I'm not sure what you're referring to here; could you clarify? > > It's true that device-mapper devices don't need the actual keyslot management. > But they do need the ability to expose crypto capabilities as well as a key > eviction function. And those are currently handled by > "struct blk_keyslot_manager". Hence the need for a "passthrough keyslot > manager" that does those other things but not the actual keyslot management. > > FWIW, I suggested splitting these up, but you disagreed and said you wanted > the > crypto capabilities to remain part of the blk_keyslot_manager > (https://lkml.kernel.org/linux-block/20200327170047.ga24...@infradead.org/). > If you've now changed your mind, please be clear about it. > I thought what Christoph meant (and of course, please let us know if I'm misunderstanding you, Christoph) was that if blk-mq handled all the blk-crypto stuff including deciding whether to use the blk-crypto-fallback, and blk-mq was responsible for calling out to blk-crypto-fallback if required, then the device mapper wouldn't need to expose any capabilities at all... or at least not for bio-based device mapper devices, since bios would go through the device mapper and eventually hit blk-mq which would then handle crypto appropriately. We couldn't do that because the crypto ciphers for the blk-crypto-fallback couldn't be allocated on the data path (so we needed fscrypt to ask blk-crypto to check whether the underlying device supported the crypto capabilities it required, and allocate ciphers appropriately, before the data path required the ciphers). I'm checking to see if anything has changed w.r.t allocating crypto ciphers on the data path (and checking if memalloc_noio_save/restore() helps with that). > - Eric
[PATCH V4 6/6] can: flexcan: add CAN wakeup function for i.MX8QM
The System Controller Firmware (SCFW) is a low-level system function
which runs on a dedicated Cortex-M core to provide power, clock, and
resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
(QM, QP), and i.MX8QX (QXP, DX). SCU driver manages the IPC interface
between host CPU and the SCU firmware running on M4.
For i.MX8QM, stop mode request is controlled by System Controller Unit(SCU)
firmware, this patch introduces FLEXCAN_QUIRK_SETUP_STOP_MODE_SCFW quirk
for this function.
Signed-off-by: Joakim Zhang
---
drivers/net/can/flexcan.c | 123 --
1 file changed, 106 insertions(+), 17 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 8f578c867493..1f2adbc606f5 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -9,6 +9,7 @@
//
// Based on code originally by Andrey Volkov
+#include
#include
#include
#include
@@ -17,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -242,6 +244,8 @@
#define FLEXCAN_QUIRK_SUPPORT_FD BIT(9)
/* support memory detection and correction */
#define FLEXCAN_QUIRK_SUPPORT_ECC BIT(10)
+/* Setup stop mode with SCU firmware to support wakeup */
+#define FLEXCAN_QUIRK_SETUP_STOP_MODE_SCFW BIT(11)
/* Structure of the message buffer */
struct flexcan_mb {
@@ -347,6 +351,7 @@ struct flexcan_priv {
u8 mb_count;
u8 mb_size;
u8 clk_src; /* clock source of CAN Protocol Engine */
+ u8 scu_idx;
u64 rx_mask;
u64 tx_mask;
@@ -358,6 +363,9 @@ struct flexcan_priv {
struct regulator *reg_xceiver;
struct flexcan_stop_mode stm;
+ /* IPC handle when setup stop mode by System Controller firmware(scfw)
*/
+ struct imx_sc_ipc *sc_ipc_handle;
+
/* Read and Write APIs */
u32 (*read)(void __iomem *addr);
void (*write)(u32 val, void __iomem *addr);
@@ -387,7 +395,7 @@ static const struct flexcan_devtype_data
fsl_imx6q_devtype_data = {
static const struct flexcan_devtype_data fsl_imx8qm_devtype_data = {
.quirks = FLEXCAN_QUIRK_DISABLE_RXFG | FLEXCAN_QUIRK_ENABLE_EACEN_RRS |
FLEXCAN_QUIRK_USE_OFF_TIMESTAMP |
FLEXCAN_QUIRK_BROKEN_PERR_STATE |
- FLEXCAN_QUIRK_SUPPORT_FD,
+ FLEXCAN_QUIRK_SUPPORT_FD | FLEXCAN_QUIRK_SETUP_STOP_MODE_SCFW,
};
static struct flexcan_devtype_data fsl_imx8mp_devtype_data = {
@@ -546,18 +554,42 @@ static void flexcan_enable_wakeup_irq(struct flexcan_priv
*priv, bool enable)
priv->write(reg_mcr, ®s->mcr);
}
+static int flexcan_stop_mode_enable_scfw(struct flexcan_priv *priv, bool
enabled)
+{
+ u8 idx = priv->scu_idx;
+ u32 rsrc_id, val;
+
+ rsrc_id = IMX_SC_R_CAN(idx);
+
+ if (enabled)
+ val = 1;
+ else
+ val = 0;
+
+ /* stop mode request via scu firmware */
+ return imx_sc_misc_set_control(priv->sc_ipc_handle, rsrc_id,
+ IMX_SC_C_IPG_STOP, val);
+}
+
static inline int flexcan_enter_stop_mode(struct flexcan_priv *priv)
{
struct flexcan_regs __iomem *regs = priv->regs;
u32 reg_mcr;
+ int ret;
reg_mcr = priv->read(®s->mcr);
reg_mcr |= FLEXCAN_MCR_SLF_WAK;
priv->write(reg_mcr, ®s->mcr);
/* enable stop request */
- regmap_update_bits(priv->stm.gpr, priv->stm.req_gpr,
- 1 << priv->stm.req_bit, 1 << priv->stm.req_bit);
+ if (priv->devtype_data->quirks & FLEXCAN_QUIRK_SETUP_STOP_MODE_SCFW) {
+ ret = flexcan_stop_mode_enable_scfw(priv, true);
+ if (ret < 0)
+ return ret;
+ } else {
+ regmap_update_bits(priv->stm.gpr, priv->stm.req_gpr,
+ 1 << priv->stm.req_bit, 1 <<
priv->stm.req_bit);
+ }
return flexcan_low_power_enter_ack(priv);
}
@@ -566,10 +598,17 @@ static inline int flexcan_exit_stop_mode(struct
flexcan_priv *priv)
{
struct flexcan_regs __iomem *regs = priv->regs;
u32 reg_mcr;
+ int ret;
/* remove stop request */
- regmap_update_bits(priv->stm.gpr, priv->stm.req_gpr,
- 1 << priv->stm.req_bit, 0);
+ if (priv->devtype_data->quirks & FLEXCAN_QUIRK_SETUP_STOP_MODE_SCFW) {
+ ret = flexcan_stop_mode_enable_scfw(priv, false);
+ if (ret < 0)
+ return ret;
+ } else {
+ regmap_update_bits(priv->stm.gpr, priv->stm.req_gpr,
+ 1 << priv->stm.req_bit, 0);
+ }
reg_mcr = priv->read(®s->mcr);
reg_mcr &= ~FLEXCAN_MCR_SLF_WAK;
@@ -1838,7 +1877,7 @@ static void unregister_flexcandev(struct net_device *dev)
unregister_candev(dev);
}
-static int flexcan_setup_stop_mode(struct platform_device *pdev)
+static int flexcan_setup_stop_mode_gpr(struct plat
[PATCH V4 0/6] can: flexcan: add stop mode support for i.MX8QM
The first patch from Liu Ying aims to export SCU symbols for SoCs w/wo SCU, so that no need to check CONFIG_IMX_SCU in the specific driver. The following patches are flexcan fixes and add stop mode support for i.MX8QM. ChangeLogs: V3->V4: * can_idx->scu_idx. * return imx_scu_get_handle(&priv->sc_ipc_handle); * failed_canregister->failed_setup_stop_mode. V2->V3: * define IMX_SC_R_CAN(x) in rsrc.h * remove error message on -EPROBE_DEFER. * split disable wakeup patch into separate one. V1->V2: * split ECC fix patches into separate patches. * free can dev if failed to setup stop mode. * disable wakeup on flexcan_remove. * add FLEXCAN_IMX_SC_R_CAN macro helper. * fsl,can-index->fsl,scu-index. * move fsl,scu-index and priv->can_idx into * flexcan_setup_stop_mode_scfw() * prove failed if failed to setup stop mode. Joakim Zhang (5): dt-bindings: can: flexcan: fix fsl,clk-source property dt-bindings: can: flexcan: add fsl,scu-index property to indicate a resource can: flexcan: rename macro FLEXCAN_QUIRK_SETUP_STOP_MODE -> FLEXCAN_QUIRK_SETUP_STOP_MODE_GPR dt-bindings: firmware: add IMX_SC_R_CAN(x) macro for CAN can: flexcan: add CAN wakeup function for i.MX8QM Liu Ying (1): firmware: imx: always export SCU symbols .../bindings/net/can/fsl-flexcan.txt | 8 +- drivers/net/can/flexcan.c | 131 +++--- include/dt-bindings/firmware/imx/rsrc.h | 1 + include/linux/firmware/imx/ipc.h | 15 ++ include/linux/firmware/imx/svc/misc.h | 23 +++ 5 files changed, 156 insertions(+), 22 deletions(-) -- 2.17.1
[PATCH V4 5/6] dt-bindings: firmware: add IMX_SC_R_CAN(x) macro for CAN
Add IMX_SC_R_CAN(x) macro for CAN. Suggested-by: Marc Kleine-Budde Signed-off-by: Joakim Zhang --- include/dt-bindings/firmware/imx/rsrc.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/dt-bindings/firmware/imx/rsrc.h b/include/dt-bindings/firmware/imx/rsrc.h index 54278d5c1856..43885056557c 100644 --- a/include/dt-bindings/firmware/imx/rsrc.h +++ b/include/dt-bindings/firmware/imx/rsrc.h @@ -111,6 +111,7 @@ #define IMX_SC_R_CAN_0 105 #define IMX_SC_R_CAN_1 106 #define IMX_SC_R_CAN_2 107 +#define IMX_SC_R_CAN(x)(IMX_SC_R_CAN_0 + (x)) #define IMX_SC_R_DMA_1_CH0 108 #define IMX_SC_R_DMA_1_CH1 109 #define IMX_SC_R_DMA_1_CH2 110 -- 2.17.1
[PATCH V4 1/6] firmware: imx: always export SCU symbols
From: Liu Ying
Always export SCU symbols for both SCU SoCs and non-SCU SoCs to avoid
build error.
Signed-off-by: Liu Ying
Signed-off-by: Peng Fan
Signed-off-by: Joakim Zhang
---
include/linux/firmware/imx/ipc.h | 15 +++
include/linux/firmware/imx/svc/misc.h | 23 +++
2 files changed, 38 insertions(+)
diff --git a/include/linux/firmware/imx/ipc.h b/include/linux/firmware/imx/ipc.h
index 891057434858..300fa253fc30 100644
--- a/include/linux/firmware/imx/ipc.h
+++ b/include/linux/firmware/imx/ipc.h
@@ -34,6 +34,7 @@ struct imx_sc_rpc_msg {
uint8_t func;
};
+#if IS_ENABLED(CONFIG_IMX_SCU)
/*
* This is an function to send an RPC message over an IPC channel.
* It is called by client-side SCFW API function shims.
@@ -55,4 +56,18 @@ int imx_scu_call_rpc(struct imx_sc_ipc *ipc, void *msg, bool
have_resp);
* @return Returns an error code (0 = success, failed if < 0)
*/
int imx_scu_get_handle(struct imx_sc_ipc **ipc);
+
+#else
+static inline int
+imx_scu_call_rpc(struct imx_sc_ipc *ipc, void *msg, bool have_resp)
+{
+ return -EIO;
+}
+
+static inline int imx_scu_get_handle(struct imx_sc_ipc **ipc)
+{
+ return -EIO;
+}
+#endif
+
#endif /* _SC_IPC_H */
diff --git a/include/linux/firmware/imx/svc/misc.h
b/include/linux/firmware/imx/svc/misc.h
index 031dd4d3c766..d255048f17de 100644
--- a/include/linux/firmware/imx/svc/misc.h
+++ b/include/linux/firmware/imx/svc/misc.h
@@ -46,6 +46,7 @@ enum imx_misc_func {
* Control Functions
*/
+#if IS_ENABLED(CONFIG_IMX_SCU)
int imx_sc_misc_set_control(struct imx_sc_ipc *ipc, u32 resource,
u8 ctrl, u32 val);
@@ -55,4 +56,26 @@ int imx_sc_misc_get_control(struct imx_sc_ipc *ipc, u32
resource,
int imx_sc_pm_cpu_start(struct imx_sc_ipc *ipc, u32 resource,
bool enable, u64 phys_addr);
+#else
+static inline int
+imx_sc_misc_set_control(struct imx_sc_ipc *ipc, u32 resource,
+ u8 ctrl, u32 val)
+{
+ return -EIO;
+}
+
+static inline int
+imx_sc_misc_get_control(struct imx_sc_ipc *ipc, u32 resource,
+ u8 ctrl, u32 *val)
+{
+ return -EIO;
+}
+
+static inline int imx_sc_pm_cpu_start(struct imx_sc_ipc *ipc, u32 resource,
+ bool enable, u64 phys_addr)
+{
+ return -EIO;
+}
+#endif
+
#endif /* _SC_MISC_API_H */
--
2.17.1
[PATCH V4 2/6] dt-bindings: can: flexcan: fix fsl,clk-source property
Correct fsl,clk-source example since flexcan driver uses "of_property_read_u8"
to get this property.
Fixes: 9d733992772d ("dt-bindings: can: flexcan: add PE clock source property
to device tree")
Signed-off-by: Joakim Zhang
---
Documentation/devicetree/bindings/net/can/fsl-flexcan.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
index e10b6eb955e1..6af67f5e581c 100644
--- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
+++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
@@ -53,5 +53,5 @@ Example:
interrupts = <48 0x2>;
interrupt-parent = <&mpic>;
clock-frequency = <2>; // filled in by bootloader
- fsl,clk-source = <0>; // select clock source 0 for PE
+ fsl,clk-source = /bits/ 8 <0>; // select clock source 0 for PE
};
--
2.17.1
[PATCH V4 4/6] can: flexcan: rename macro FLEXCAN_QUIRK_SETUP_STOP_MODE -> FLEXCAN_QUIRK_SETUP_STOP_MODE_GPR
This patch intends to rename FLEXCAN_QUIRK_SETUP_STOP_MODE quirk
to FLEXCAN_QUIRK_SETUP_STOP_MODE_GRP for non-scu SoCs, coming patch will
add quirk for scu SoCs.
For non-scu SoCs, setup stop mode with GPR register.
For scu SoCs, setup stop mode with SCU firmware.
Signed-off-by: Joakim Zhang
---
drivers/net/can/flexcan.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 881799bd9c5e..8f578c867493 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -236,8 +236,8 @@
#define FLEXCAN_QUIRK_BROKEN_PERR_STATE BIT(6)
/* default to BE register access */
#define FLEXCAN_QUIRK_DEFAULT_BIG_ENDIAN BIT(7)
-/* Setup stop mode to support wakeup */
-#define FLEXCAN_QUIRK_SETUP_STOP_MODE BIT(8)
+/* Setup stop mode with GPR to support wakeup */
+#define FLEXCAN_QUIRK_SETUP_STOP_MODE_GPR BIT(8)
/* Support CAN-FD mode */
#define FLEXCAN_QUIRK_SUPPORT_FD BIT(9)
/* support memory detection and correction */
@@ -381,7 +381,7 @@ static const struct flexcan_devtype_data
fsl_imx28_devtype_data = {
static const struct flexcan_devtype_data fsl_imx6q_devtype_data = {
.quirks = FLEXCAN_QUIRK_DISABLE_RXFG | FLEXCAN_QUIRK_ENABLE_EACEN_RRS |
FLEXCAN_QUIRK_USE_OFF_TIMESTAMP |
FLEXCAN_QUIRK_BROKEN_PERR_STATE |
- FLEXCAN_QUIRK_SETUP_STOP_MODE,
+ FLEXCAN_QUIRK_SETUP_STOP_MODE_GPR,
};
static const struct flexcan_devtype_data fsl_imx8qm_devtype_data = {
@@ -393,7 +393,7 @@ static const struct flexcan_devtype_data
fsl_imx8qm_devtype_data = {
static struct flexcan_devtype_data fsl_imx8mp_devtype_data = {
.quirks = FLEXCAN_QUIRK_DISABLE_RXFG | FLEXCAN_QUIRK_ENABLE_EACEN_RRS |
FLEXCAN_QUIRK_DISABLE_MECR | FLEXCAN_QUIRK_USE_OFF_TIMESTAMP |
- FLEXCAN_QUIRK_BROKEN_PERR_STATE | FLEXCAN_QUIRK_SETUP_STOP_MODE
|
+ FLEXCAN_QUIRK_BROKEN_PERR_STATE |
FLEXCAN_QUIRK_SETUP_STOP_MODE_GPR |
FLEXCAN_QUIRK_SUPPORT_FD | FLEXCAN_QUIRK_SUPPORT_ECC,
};
@@ -2043,7 +2043,7 @@ static int flexcan_probe(struct platform_device *pdev)
of_can_transceiver(dev);
devm_can_led_init(dev);
- if (priv->devtype_data->quirks & FLEXCAN_QUIRK_SETUP_STOP_MODE) {
+ if (priv->devtype_data->quirks & FLEXCAN_QUIRK_SETUP_STOP_MODE_GPR) {
err = flexcan_setup_stop_mode(pdev);
if (err)
dev_dbg(&pdev->dev, "failed to setup stop-mode\n");
--
2.17.1
[PATCH V4 3/6] dt-bindings: can: flexcan: add fsl,scu-index property to indicate a resource
For SoCs with SCU support, need setup stop mode via SCU firmware, so this property can help indicate a resource in SCU firmware. Signed-off-by: Joakim Zhang --- Documentation/devicetree/bindings/net/can/fsl-flexcan.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt index 6af67f5e581c..38a7da4fef3f 100644 --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt +++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt @@ -43,6 +43,11 @@ Optional properties: 0: clock source 0 (oscillator clock) 1: clock source 1 (peripheral clock) +- fsl,scu-index: The scu index of CAN instance. + For SoCs with SCU support, need setup stop mode via SCU firmware, + so this property can help indicate a resource. It supports up to + 3 CAN instances now, so the value should be 0, 1, or 2. + - wakeup-source: enable CAN remote wakeup Example: @@ -54,4 +59,5 @@ Example: interrupt-parent = <&mpic>; clock-frequency = <2>; // filled in by bootloader fsl,clk-source = /bits/ 8 <0>; // select clock source 0 for PE + fsl,scu-index = /bits/ 8 <1>; // the second CAN instance }; -- 2.17.1
Re: [PATCH v5 1/5] arm64: Add framework to turn IPI as NMI
On Tue, 20 Oct 2020 at 18:02, Marc Zyngier wrote: > > On 2020-10-20 13:25, Daniel Thompson wrote: > > On Tue, Oct 20, 2020 at 04:52:43PM +0530, Sumit Garg wrote: > > [...] > > >> So in general, IPI as a normal IRQ is still useful for debugging but > >> it can't debug a core which is stuck in deadlock with interrupts > >> disabled. > >> > >> And since we choose override default implementations for pseudo NMI > >> support, we need to be backwards compatible for platforms which don't > >> possess pseudo NMI support. > > > > Do the fallback implementations require a new IPI? The fallbacks > > could rely on existing mechanisms such as the smp_call_function > > family. > > Indeed. I'd be worried of using that mechanism for NMIs, but normal > IPIs should stick to the normal cross-call stuff. Yes, the fallback implementations could rely on existing cross-call stuff but current framework only allows this fallback choice at compile time and to make this choice at runtime, we need additional framework changes like allowing arch_trigger_cpumask_backtrace() to return a boolean in order to switch to fallback mode, similar would be the case for kgdb. I think this should be doable but I am still not sure regarding the advantages of using existing IPI vs new IPI (which we will already use in case of pseudo NMI support) as normal IRQ. > > The jury is still out on why this is a good idea, given that it > doesn't work in the only interesting case (deadlocked CPUs). I think CPU soft-lockups (interrupts enabled) is an interesting case to debug as well. -Sumit > > M. > -- > Jazz is not dead. It just smells funny...
[PATCH] can: vxcan: Fix memleak in vxcan_newlink
When rtnl_configure_link() fails, peer needs to be freed just like when register_netdevice() fails. Signed-off-by: Dinghao Liu --- drivers/net/can/vxcan.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/can/vxcan.c b/drivers/net/can/vxcan.c index d6ba9426be4d..aefc5a61d239 100644 --- a/drivers/net/can/vxcan.c +++ b/drivers/net/can/vxcan.c @@ -244,6 +244,7 @@ static int vxcan_newlink(struct net *net, struct net_device *dev, unregister_network_device: unregister_netdevice(peer); + free_netdev(peer); return err; } -- 2.17.1
Re: [PATCH v2] fat: Add KUnit tests for checksums and timestamps
David Gow writes: >> Hm, can this export only if FAT_KUNIT_TEST is builtin or module (maybe >> #if IS_ENABLED(...))? And #if will also be worked as the comment too. >> > > That's possible, but I'd prefer to export it unconditionally for two reasons: > 1. It'd make it possible to build the fat_test module without having > to rebuild the whole kernel/fat. > 2. It'd be consistent with fat_time_unix2fat(), which is exported for > use in vfat/msdos anyway. > > Neither of those are dealbreakers, though, so if you'd still prefer > this to be behind an ifdef, I'll change it. OK. If nobody complain, let's export. However, then, can you add the comment instead of ifdef to mark for kunit? Thanks. -- OGAWA Hirofumi
Re: [PATCH] firmware: gsmi: Drop the use of dma_pool_* API functions
On Tue, Oct 20, 2020 at 10:01:41PM -0700, Furquan Shaikh wrote: > GSMI driver uses dma_pool_* API functions for buffer allocation > because it requires that the SMI buffers are allocated within 32-bit > physical address space. However, this does not work well with IOMMU > since there is no real device and hence no domain associated with the > device. > > Since this is not a real device, it does not require any device > address(IOVA) for the buffer allocations. The only requirement is to > ensure that the physical address allocated to the buffer is within > 32-bit physical address space. This change allocates a page using > `get_zeroed_page()` and passes in GFP_DMA32 flag to ensure that the > page allocation is done in the DMA32 zone. All the buffer allocation > requests for gsmi_buf are then satisfed using this pre-allocated page > for the device. Are you sure that "GFP_DMA32" really does what you think it does? A "normal" call with GFP_KERNEL" will give you memory that is properly dma-able. We should not be adding new GFP_DMA* users in the kernel in these days, just call dma_alloc*() and you should be fine. thanks, greg k-h
Re: [PATCH v2 12/14] perf arm-spe: Add more sub classes for operation packet
On Tue, Oct 20, 2020 at 10:54:57PM +0100, André Przywara wrote:
> On 29/09/2020 14:39, Leo Yan wrote:
>
> Hi,
>
> > For the operation type packet payload with load/store class, it misses
> > to support these sub classes:
> >
> > - A load/store targeting the general-purpose registers;
> > - A load/store targeting unspecified registers;
> > - The ARMv8.4 nested virtualisation extension can redirect system
> > register accesses to a memory page controlled by the hypervisor.
> > The SPE profiling feature in newer implementations can tag those
> > memory accesses accordingly.
> >
> > Add the bit pattern describing load/store sub classes, so that the perf
> > tool can decode it properly.
> >
> > Inspired by Andre Przywara, refined the commit log and code for more
> > clear description.
> >
> > Co-developed-by: Andre Przywara
> > Signed-off-by: Leo Yan
> > ---
> > .../util/arm-spe-decoder/arm-spe-pkt-decoder.c| 15 +++
> > 1 file changed, 15 insertions(+)
> >
> > diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > index a848c784f4cf..57a2d5494838 100644
> > --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > @@ -378,6 +378,21 @@ int arm_spe_pkt_desc(const struct arm_spe_pkt *packet,
> > char *buf,
> > ret = arm_spe_pkt_snprintf(&buf, &blen, "
> > SIMD-FP");
> > if (ret < 0)
> > return ret;
> > + } else if ((payload & SPE_OP_PKT_LDST_SUBCLASS_MASK) ==
>
> These three and the one above use the same mask, should this go into a
> switch case? Move this block to the end, then do:
> switch (payload & SPE_OP_PKT_LDST_SUBCLASS_MASK) {
> case SPE_OP_PKT_LDST_SUBCLASS_GP_REG:
> ...
> case SPE_OP_PKT_LDST_SUBCLASS_UNSPEC_REG:
> ...
> Maybe even assign just a string pointer inside, then have one snprintf.
> Haven't checked it that *really* looks better, though.
Good point, will follow up this suggestion.
> Also those later checks are quite indented, shall those be moved to
> helper functions? Again just an idea
Yeah, I also considered to divide into small functions to handle
different types of packets so can avoid deep indention. Will tweak
patches for this.
Very appreciate for your detailed reviewing and suggestions throughout
the patch set!
Leo
Re: [PATCH v2 14/14] perf arm-spe: Add support for ARMv8.3-SPE
On Tue, Oct 20, 2020 at 10:54:44PM +0100, André Przywara wrote:
> On 29/09/2020 14:39, Leo Yan wrote:
>
> Hi,
>
> > From: Wei Li
> >
> > This patch is to support Armv8.3 extension for SPE, it adds alignment
> > field in the Events packet and it supports the Scalable Vector Extension
> > (SVE) for Operation packet and Events packet with two additions:
> >
> > - The vector length for SVE operations in the Operation Type packet;
> > - The incomplete predicate and empty predicate fields in the Events
> > packet.
> >
> > Signed-off-by: Wei Li
> > Signed-off-by: Leo Yan
> > ---
> > .../arm-spe-decoder/arm-spe-pkt-decoder.c | 84 ++-
> > .../arm-spe-decoder/arm-spe-pkt-decoder.h | 6 ++
> > 2 files changed, 87 insertions(+), 3 deletions(-)
> >
> > diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > index 05a4c74399d7..3ec381fddfcb 100644
> > --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > @@ -342,14 +342,73 @@ int arm_spe_pkt_desc(const struct arm_spe_pkt
> > *packet, char *buf,
> > return ret;
> > }
> > }
> > + if (idx > 2) {
>
> As I mentioned in the other patch, I doubt this extra comparison is
> useful. Does that protect us from anything?
It's the same reason with Event packet which have explained for replying
patch 10, the condition is to respect the SPE specifiction:
E[11], byte 1, bit [11], when SZ == 0b10 , or SZ == 0b11
Alignment.
...
Otherwise this bit reads-as-zero.
So we gives higher priority for checking payload size than the Event
bit setting; if you have other thinking for this, please let me know.
> > + if (payload & SPE_EVT_PKT_ALIGNMENT) {
>
> Mmh, but this is bit 11, right?
Yes.
> So would need to go into the (idx > 1)
> section (covering bits 8-15)? Another reason to ditch this comparison above.
As has explained in patch 10, idx is not the same thing with "sz"
field; "idx" stands for payload length in bytes, so:
idx = 1 << sz
The spec defines the sz is 2 or 3, thus idx is 4 or 8; so this is why
here use the condition "(idx > 2)".
I think here need to refine code for more explict expression so can
avoid confusion. So I think it's better to condition such like:
if (payload_len >= 4) {
...
}
> > + ret = snprintf(buf, buf_len, " ALIGNMENT");
> > + if (ret < 0)
> > + return ret;
> > + buf += ret;
> > + blen -= ret;
>
> Shouldn't we use the new arm_spe_pkt_snprintf() function here as well?
> Or is there a reason that this doesn't work?
Goot point. Will change to use arm_spe_pkt_snprintf().
> > + }
> > + if (payload & SPE_EVT_PKT_SVE_PARTIAL_PREDICATE) {
> > + ret = snprintf(buf, buf_len, "
> > SVE-PARTIAL-PRED");
> > + if (ret < 0)
> > + return ret;
> > + buf += ret;
> > + blen -= ret;
> > + }
> > + if (payload & SPE_EVT_PKT_SVE_EMPTY_PREDICATE) {
> > + ret = snprintf(buf, buf_len, " SVE-EMPTY-PRED");
> > + if (ret < 0)
> > + return ret;
> > + buf += ret;
> > + blen -= ret;
> > + }
> > + }
> > +
> > return buf_len - blen;
> >
> > case ARM_SPE_OP_TYPE:
> > switch (idx) {
> > case SPE_OP_PKT_HDR_CLASS_OTHER:
> > - return arm_spe_pkt_snprintf(&buf, &blen,
> > - payload &
> > SPE_OP_PKT_OTHER_SUBCLASS_COND ?
> > - "COND-SELECT" : "INSN-OTHER");
> > + if ((payload & SPE_OP_PKT_OTHER_SVE_SUBCLASS_MASK) ==
> > + SPE_OP_PKT_OTHER_SUBCLASS_SVG_OP) {
> > +
> > + ret = arm_spe_pkt_snprintf(&buf, &blen,
> > "SVE-OTHER");
> > + if (ret < 0)
> > + return ret;
> > +
> > + /* Effective vector length: step is 32 bits */
> > + ret = arm_spe_pkt_snprintf(&buf, &blen, " EVLEN
> > %d",
> > + 32 << ((payload &
> > SPE_OP_PKT_SVE_EVL_MASK) >>
> > + SPE_OP_PKT_SVE_EVL_SHIFT));
>
> Can you move this into a macro, and add a comment about how this works?
> People might get confused over the "32 << something".
Yeah, will refine for it.
Thanks,
Leo
Re: [PATCH] FROMLIST: input: add 2 kind of switch
On Wed, Oct 21, 2020 at 12:12:16PM +0900, HyungJae Im wrote:
> >From ec9859ee01b7bc0e04255971e0fe97348847dab7 Mon Sep 17 00:00:00 2001
You sent this 3 times, why?
And why is this in the body of the email, have you read the "how to send
your first kernel patch" document at kernelnewbies.org?
> From: "hj2.im"
> Date: Tue, 20 Oct 2020 16:57:04 +0900
> Subject: [PATCH] FROMLIST: input: add 2 kind of switch
What does "FROMLIST:" mean?
>
> We need support to various accessories on the device,
> some switch does not exist in switch list.
> So added switch for the following purpose.
>
> SW_COVER_ATTACHED is for the checking the cover
> attached or not on the device. SW_EXT_PEN_ATTACHED is for the
> checking the external pen attached or not on the device
>
> Signed-off-by: hj2.im
As per the kernel documentation, you need to use your real name here,
please do so.
> ---
> include/linux/mod_devicetable.h| 2 +-
> include/uapi/linux/input-event-codes.h | 4 +++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> index 5b08a473cdba..897f5a3e7721 100644
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -320,7 +320,7 @@ struct pcmcia_device_id {
> #define INPUT_DEVICE_ID_LED_MAX 0x0f
> #define INPUT_DEVICE_ID_SND_MAX 0x07
> #define INPUT_DEVICE_ID_FF_MAX 0x7f
> -#define INPUT_DEVICE_ID_SW_MAX 0x10
> +#define INPUT_DEVICE_ID_SW_MAX 0x12
> #define INPUT_DEVICE_ID_PROP_MAX 0x1f
>
> #define INPUT_DEVICE_ID_MATCH_BUS1
> diff --git a/include/uapi/linux/input-event-codes.h
> b/include/uapi/linux/input-event-codes.h
> index 0c2e27d28e0a..8ca2acee1f92 100644
> --- a/include/uapi/linux/input-event-codes.h
> +++ b/include/uapi/linux/input-event-codes.h
> @@ -889,7 +889,9 @@
> #define SW_MUTE_DEVICE 0x0e /* set = device disabled */
> #define SW_PEN_INSERTED 0x0f /* set = pen inserted */
> #define SW_MACHINE_COVER 0x10 /* set = cover closed */
> -#define SW_MAX 0x10
> +#define SW_COVER_ATTACHED0x11 /* set = cover attached */
> +#define SW_EXT_PEN_ATTACHED 0x12 /* set = external pen attached */
Is there an in-kernel user for these values anywhere? Please submit
this patch along with the users at the same time, otherwise this change
makes no sense at all.
thanks,
greg k-h
Re: [PATCH 2/2] ARM: dts: tacoma: Add reserved memory for ramoops
On Fri, 16 Oct 2020 at 04:36, Andrew Jeffery wrote:
>
> Reserve a 1.5MiB region of memory to record kmsg dumps, console and
> userspace message state into 16kiB ring-buffer slots. The sizing allows
> for up to 32 dumps to be captured and read out.
>
> Set max-reason to KMSG_DUMP_EMERG to capture bad-path reboots.
>
> Signed-off-by: Andrew Jeffery
> ---
> arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts
> b/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts
> index 46f2f538baba..4f7e9b490e1a 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts
> @@ -26,6 +26,15 @@ reserved-memory {
> #size-cells = <1>;
> ranges;
>
> + ramoops@b9e8 {
> + compatible = "ramoops";
> + reg = <0xb9e8 0x18>;
I take that r-b back. When booting, we see:
[0.00] region@ba00 (0xb800--0xbc00) overlaps with
ramoops@b9e8 (0xb9e8--0xba00)
Which appears to be a true statement.
> + record-size = <0x4000>;
> + console-size = <0x4000>;
> + pmsg-size = <0x4000>;
> + max-reason = <3>; /* KMSG_DUMP_EMERG */
> + };
> +
> flash_memory: region@ba00 {
> no-map;
> reg = <0xb800 0x400>; /* 64M */
> --
> 2.25.1
>
arm64 build broken on linux next 20201021 - include/uapi/asm-generic/unistd.h:862:26: error: array index in initializer exceeds array bounds
arm64 build broken while building linux next 20201021 tag. include/uapi/asm-generic/unistd.h:862:26: error: array index in initializer exceeds array bounds #define __NR_watch_mount 441 ^ Reported-by: Naresh Kamboju build error log on arm64: include/uapi/asm-generic/unistd.h:862:26: error: array index in initializer exceeds array bounds #define __NR_watch_mount 441 ^ arch/arm64/kernel/sys.c:56:29: note: in definition of macro '__SYSCALL' #define __SYSCALL(nr, sym) [nr] = __arm64_##sym, ^~ include/uapi/asm-generic/unistd.h:863:11: note: in expansion of macro '__NR_watch_mount' __SYSCALL(__NR_watch_mount, sys_watch_mount) ^~~~ include/uapi/asm-generic/unistd.h:862:26: note: (near initialization for 'sys_call_table') #define __NR_watch_mount 441 ^ arch/arm64/kernel/sys.c:56:29: note: in definition of macro '__SYSCALL' #define __SYSCALL(nr, sym) [nr] = __arm64_##sym, ^~ include/uapi/asm-generic/unistd.h:863:11: note: in expansion of macro '__NR_watch_mount' __SYSCALL(__NR_watch_mount, sys_watch_mount) ^~~~ arch/arm64/kernel/sys.c:56:35: warning: excess elements in array initializer #define __SYSCALL(nr, sym) [nr] = __arm64_##sym, ^ include/uapi/asm-generic/unistd.h:863:1: note: in expansion of macro '__SYSCALL' __SYSCALL(__NR_watch_mount, sys_watch_mount) ^ arch/arm64/kernel/sys.c:56:35: note: (near initialization for 'sys_call_table') #define __SYSCALL(nr, sym) [nr] = __arm64_##sym, ^ include/uapi/asm-generic/unistd.h:863:1: note: in expansion of macro '__SYSCALL' __SYSCALL(__NR_watch_mount, sys_watch_mount) ^ scripts/Makefile.build:283: recipe for target 'arch/arm64/kernel/sys.o' failed | make[3]: *** [arch/arm64/kernel/sys.o] Error 1 scripts/Makefile.build:500: recipe for target 'arch/arm64/kernel' failed | make[2]: *** [arch/arm64/kernel] Error 2 full test log, https://ci.linaro.org/view/lkft/job/openembedded-lkft-linux-next/DISTRO=lkft,MACHINE=hikey,label=docker-lkft/882/consoleText -- Linaro LKFT https://lkft.linaro.org
[PATCH] firmware: gsmi: Drop the use of dma_pool_* API functions
GSMI driver uses dma_pool_* API functions for buffer allocation
because it requires that the SMI buffers are allocated within 32-bit
physical address space. However, this does not work well with IOMMU
since there is no real device and hence no domain associated with the
device.
Since this is not a real device, it does not require any device
address(IOVA) for the buffer allocations. The only requirement is to
ensure that the physical address allocated to the buffer is within
32-bit physical address space. This change allocates a page using
`get_zeroed_page()` and passes in GFP_DMA32 flag to ensure that the
page allocation is done in the DMA32 zone. All the buffer allocation
requests for gsmi_buf are then satisfed using this pre-allocated page
for the device.
In addition to that, all the code for managing the dma_pool for GSMI
platform device is dropped.
Signed-off-by: Furquan Shaikh
Reviewed-by: Prashant Malani
---
drivers/firmware/google/gsmi.c | 100 +++--
1 file changed, 71 insertions(+), 29 deletions(-)
diff --git a/drivers/firmware/google/gsmi.c b/drivers/firmware/google/gsmi.c
index 7d9367b22010..054c47346900 100644
--- a/drivers/firmware/google/gsmi.c
+++ b/drivers/firmware/google/gsmi.c
@@ -17,7 +17,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -46,7 +45,6 @@
#define DRIVER_VERSION "1.0"
#define GSMI_GUID_SIZE 16
#define GSMI_BUF_SIZE 1024
-#define GSMI_BUF_ALIGN sizeof(u64)
#define GSMI_CALLBACK 0xef
/* SMI return codes */
@@ -85,10 +83,15 @@
struct gsmi_buf {
u8 *start; /* start of buffer */
size_t length; /* length of buffer */
- dma_addr_t handle; /* dma allocation handle */
u32 address;/* physical address of buffer */
};
+struct gsmi_page {
+ unsigned long base_address; /* Base address of allocated page */
+ size_t alloc_size; /* Size of allocation */
+ size_t alloc_used; /* Amount of allocation that is used */
+};
+
static struct gsmi_device {
struct platform_device *pdev; /* platform device */
struct gsmi_buf *name_buf; /* variable name buffer */
@@ -97,7 +100,7 @@ static struct gsmi_device {
spinlock_t lock;/* serialize access to SMIs */
u16 smi_cmd;/* SMI command port */
int handshake_type; /* firmware handler interlock type */
- struct dma_pool *dma_pool; /* DMA buffer pool */
+ struct gsmi_page *page_info;/* page allocated for GSMI buffers */
} gsmi_dev;
/* Packed structures for communicating with the firmware */
@@ -146,9 +149,57 @@ MODULE_PARM_DESC(spincount,
static bool s0ix_logging_enable;
module_param(s0ix_logging_enable, bool, 0600);
+static struct gsmi_page *gsmi_page_alloc(void)
+{
+ struct gsmi_page *page_info;
+
+ page_info = kzalloc(sizeof(*page_info), GFP_KERNEL);
+ if (!page_info) {
+ printk(KERN_ERR "gsmi: out of memory\n");
+ return NULL;
+ }
+
+ page_info->base_address = get_zeroed_page(GFP_KERNEL | GFP_DMA32);
+ if (!page_info->base_address) {
+ printk(KERN_ERR "gsmi: failed to allocate page for buffers\n");
+ return NULL;
+ }
+
+ /* Ensure the entire buffer is allocated within 32bit address space */
+ if (virt_to_phys((void *)(page_info->base_address + PAGE_SIZE - 1))
+ >> 32) {
+ printk(KERN_ERR "gsmi: allocation not within 32-bit physical
address space\n");
+ free_page(page_info->base_address);
+ kfree(page_info);
+ return NULL;
+ }
+
+ page_info->alloc_size = PAGE_SIZE;
+
+ return page_info;
+}
+
+static unsigned long gsmi_page_allocate_buffer(void)
+{
+ struct gsmi_page *page_info = gsmi_dev.page_info;
+ unsigned long buf_offset = page_info->alloc_used;
+
+ if (buf_offset + GSMI_BUF_SIZE > page_info->alloc_size) {
+ printk(KERN_ERR "gsmi: out of space for buffer allocation\n");
+ return 0;
+ }
+
+ page_info->alloc_used = buf_offset + GSMI_BUF_SIZE;
+ return page_info->base_address + buf_offset;
+}
+
static struct gsmi_buf *gsmi_buf_alloc(void)
{
struct gsmi_buf *smibuf;
+ u8 *buf_addr = (u8 *)gsmi_page_allocate_buffer();
+
+ if (!buf_addr)
+ return NULL;
smibuf = kzalloc(sizeof(*smibuf), GFP_KERNEL);
if (!smibuf) {
@@ -156,14 +207,7 @@ static struct gsmi_buf *gsmi_buf_alloc(void)
return NULL;
}
- /* allocate buffer in 32bit address space */
- smibuf->start = dma_pool_alloc(gsmi_dev.dma_pool, GFP_KERNEL,
- &smibuf->handle);
- if (!smibuf->start) {
- printk(KERN_ERR "gsmi: fa
Re: [f2fs-dev] [PATCH] f2fs: add compr_inode and compr_blocks sysfs nodes
Both values are from memory values. 2020년 10월 21일 (수) 오후 1:36, Eric Biggers 님이 작성: > > On Fri, Oct 16, 2020 at 02:14:55PM +0900, Daeho Jeong wrote: > > From: Daeho Jeong > > > > Added compr_inode to show compressed inode count and compr_blocks to > > show compressed block count in sysfs. > > > > Signed-off-by: Daeho Jeong > > --- > > Documentation/ABI/testing/sysfs-fs-f2fs | 10 ++ > > fs/f2fs/sysfs.c | 17 + > > 2 files changed, 27 insertions(+) > > > > diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs > > b/Documentation/ABI/testing/sysfs-fs-f2fs > > index 834d0becae6d..a01c26484c69 100644 > > --- a/Documentation/ABI/testing/sysfs-fs-f2fs > > +++ b/Documentation/ABI/testing/sysfs-fs-f2fs > > @@ -350,3 +350,13 @@ Date:April 2020 > > Contact: "Daeho Jeong" > > Description: Give a way to change iostat_period time. 3secs by default. > > The new iostat trace gives stats gap given the period. > > + > > +What:/sys/fs/f2fs//compr_inode > > +Date:October 2020 > > +Contact: "Daeho Jeong" > > +Description: Show compressed inode count > > + > > +What:/sys/fs/f2fs//compr_blocks > > +Date:October 2020 > > +Contact: "Daeho Jeong" > > +Description: Show compressed block count > > Is it the count in memory, or on disk? > > - Eric
Re: [PATCH v2 10/14] perf arm-spe: Refactor event type handling
On Tue, Oct 20, 2020 at 10:54:16PM +0100, André Przywara wrote:
> On 29/09/2020 14:39, Leo Yan wrote:
>
> Hi,
>
> > Use macros instead of the enum values for event types, this is more
> > directive and without bit shifting when parse packet.
> >
> > Signed-off-by: Leo Yan
> > ---
> > .../util/arm-spe-decoder/arm-spe-decoder.c| 16 +++---
> > .../util/arm-spe-decoder/arm-spe-decoder.h| 17 --
> > .../arm-spe-decoder/arm-spe-pkt-decoder.c | 22 +--
> > .../arm-spe-decoder/arm-spe-pkt-decoder.h | 16 ++
> > 4 files changed, 35 insertions(+), 36 deletions(-)
> >
> > diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-decoder.c
> > b/tools/perf/util/arm-spe-decoder/arm-spe-decoder.c
> > index 9d3de163d47c..ac66e7f42a58 100644
> > --- a/tools/perf/util/arm-spe-decoder/arm-spe-decoder.c
> > +++ b/tools/perf/util/arm-spe-decoder/arm-spe-decoder.c
> > @@ -168,31 +168,31 @@ static int arm_spe_read_record(struct arm_spe_decoder
> > *decoder)
> > case ARM_SPE_OP_TYPE:
> > break;
> > case ARM_SPE_EVENTS:
> > - if (payload & BIT(EV_L1D_REFILL))
> > + if (payload & SPE_EVT_PKT_L1D_REFILL)
>
> Not sure this (and the others below) are an improvement? I liked the
> enum below, and reading BIT() here tells me that it's a bitmask.
Agreed.
> > decoder->record.type |= ARM_SPE_L1D_MISS;
> >
> > - if (payload & BIT(EV_L1D_ACCESS))
> > + if (payload & SPE_EVT_PKT_L1D_ACCESS)
> > decoder->record.type |= ARM_SPE_L1D_ACCESS;
> >
> > - if (payload & BIT(EV_TLB_WALK))
> > + if (payload & SPE_EVT_PKT_TLB_WALK)
> > decoder->record.type |= ARM_SPE_TLB_MISS;
> >
> > - if (payload & BIT(EV_TLB_ACCESS))
> > + if (payload & SPE_EVT_PKT_TLB_ACCESS)
> > decoder->record.type |= ARM_SPE_TLB_ACCESS;
> >
> > if ((idx == 2 || idx == 4 || idx == 8) &&
> > - (payload & BIT(EV_LLC_MISS)))
> > + (payload & SPE_EVT_PKT_LLC_MISS))
> > decoder->record.type |= ARM_SPE_LLC_MISS;
> >
> > if ((idx == 2 || idx == 4 || idx == 8) &&
> > - (payload & BIT(EV_LLC_ACCESS)))
> > + (payload & SPE_EVT_PKT_LLC_ACCESS))
> > decoder->record.type |= ARM_SPE_LLC_ACCESS;
> >
> > if ((idx == 2 || idx == 4 || idx == 8) &&
> > - (payload & BIT(EV_REMOTE_ACCESS)))
> > + (payload & SPE_EVT_PKT_REMOTE_ACCESS))
> > decoder->record.type |= ARM_SPE_REMOTE_ACCESS;
> >
> > - if (payload & BIT(EV_MISPRED))
> > + if (payload & SPE_EVT_PKT_MISPREDICTED)
> > decoder->record.type |= ARM_SPE_BRANCH_MISS;
> >
> > break;
> > diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-decoder.h
> > b/tools/perf/util/arm-spe-decoder/arm-spe-decoder.h
> > index a5111a8d4360..24727b8ca7ff 100644
> > --- a/tools/perf/util/arm-spe-decoder/arm-spe-decoder.h
> > +++ b/tools/perf/util/arm-spe-decoder/arm-spe-decoder.h
> > @@ -13,23 +13,6 @@
> >
> > #include "arm-spe-pkt-decoder.h"
> >
> > -enum arm_spe_events {
> > - EV_EXCEPTION_GEN= 0,
> > - EV_RETIRED = 1,
> > - EV_L1D_ACCESS = 2,
> > - EV_L1D_REFILL = 3,
> > - EV_TLB_ACCESS = 4,
> > - EV_TLB_WALK = 5,
> > - EV_NOT_TAKEN= 6,
> > - EV_MISPRED = 7,
> > - EV_LLC_ACCESS = 8,
> > - EV_LLC_MISS = 9,
> > - EV_REMOTE_ACCESS= 10,
> > - EV_ALIGNMENT= 11,
> > - EV_PARTIAL_PREDICATE= 17,
> > - EV_EMPTY_PREDICATE = 18,
> > -};
>
> So what about keeping this, but moving it into the other header file?
Will do. This is more directive, especially if we consider every bit
indicates an event type :)
> coding-style.rst says: "Enums are preferred when defining several
> related constants."
Thanks for pasting the coding style, it's useful. I agree that using
BIT() + enum is better form, will refine the patch for this.
> > -
> > enum arm_spe_sample_type {
> > ARM_SPE_L1D_ACCESS = 1 << 0,
> > ARM_SPE_L1D_MISS= 1 << 1,
> > diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > index ed0f4c74dfc5..b8f343320abf 100644
> > --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > @@ -284,58 +284,58 @@ int arm_spe_pkt_desc(const struct arm_spe_pkt
> > *packet, char *buf,
> > if (ret < 0)
> >
Re: [PATCH v2 3/5] scsi: ufs: use WQ_HIGHPRI for gating work
On 10/21, Can Guo wrote: > On 2020-10-21 03:52, Jaegeuk Kim wrote: > > From: Jaegeuk Kim > > > > Must have WQ_MEM_RECLAIM > > ``WQ_MEM_RECLAIM`` > > All wq which might be used in the memory reclaim paths **MUST** > > have this flag set. The wq is guaranteed to have at least one > > execution context regardless of memory pressure. > > > > You misunderstood my point. I meant you need to give more info about why > we are adding WQ_HIGHPRI flag but not why WQ_MEM_RECLAIM must be there. Oh, I thought that WQ_HIGHPRI is telling everything tho. > > Thanks, > > Can Guo. > > > Cc: Alim Akhtar > > Cc: Avri Altman > > Cc: Can Guo > > Signed-off-by: Jaegeuk Kim > > --- > > drivers/scsi/ufs/ufshcd.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c > > index feb10ebf7a35..0858c0b55eac 100644 > > --- a/drivers/scsi/ufs/ufshcd.c > > +++ b/drivers/scsi/ufs/ufshcd.c > > @@ -1867,7 +1867,7 @@ static void ufshcd_init_clk_gating(struct ufs_hba > > *hba) > > snprintf(wq_name, ARRAY_SIZE(wq_name), "ufs_clk_gating_%d", > > hba->host->host_no); > > hba->clk_gating.clk_gating_workq = alloc_ordered_workqueue(wq_name, > > - WQ_MEM_RECLAIM); > > + WQ_MEM_RECLAIM | WQ_HIGHPRI); > > > > hba->clk_gating.is_enabled = true;
Re: [PATCH v2 5/5] scsi: ufs: fix clkgating on/off correctly
On 10/21, Can Guo wrote: > On 2020-10-21 03:52, Jaegeuk Kim wrote: > > The below call stack prevents clk_gating at every IO completion. > > We can remove the condition, ufshcd_any_tag_in_use(), since > > clkgating_work > > will check it again. > > > > I think checking ufshcd_any_tag_in_use() in either ufshcd_release() or > gate_work() can break UFS clk gating's functionality. > > ufshcd_any_tag_in_use() was introduced to replace hba->lrb_in_use. However, > they are not exactly same - ufshcd_any_tag_in_use() returns true if any tag > assigned from block layer is still in use, but tags are released > asynchronously > (through block softirq), meaning it does not reflect the real occupation of > UFS host. > That is after UFS host finishes all tasks, ufshcd_any_tag_in_use() can still > return true. > > This change only removes the check of ufshcd_any_tag_in_use() in > ufshcd_release(), > but having the check of it in gate_work() can still prevent gating from > happening. > The current change works for you maybe because the tags are release before > hba->clk_gating.delay_ms expires, but if hba->clk_gating.delay_ms is shorter > or > somehow block softirq is retarded, gate_work() may have chance to see > ufshcd_any_tag_in_use() > returns true. What do you think? I don't think this breaks clkgating, but fix the wrong condition check which prevented gate_work at all. As you mentioned, even if this schedules gate_work by racy conditions, gate_work will handle it as a last resort. > > Thanks, > > Can Guo. > > In __ufshcd_transfer_req_compl > Ihba->lrb_in_use is cleared immediately when UFS driver > finishes all tasks > > > ufshcd_complete_requests(struct ufs_hba *hba) > > ufshcd_transfer_req_compl() > > __ufshcd_transfer_req_compl() > > __ufshcd_release(hba) > > if (ufshcd_any_tag_in_use() == 1) > >return; > > ufshcd_tmc_handler(hba); > > blk_mq_tagset_busy_iter(); > > > > Cc: Alim Akhtar > > Cc: Avri Altman > > Cc: Can Guo > > Signed-off-by: Jaegeuk Kim > > --- > > drivers/scsi/ufs/ufshcd.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c > > index b5ca0effe636..cecbd4ace8b4 100644 > > --- a/drivers/scsi/ufs/ufshcd.c > > +++ b/drivers/scsi/ufs/ufshcd.c > > @@ -1746,7 +1746,7 @@ static void __ufshcd_release(struct ufs_hba *hba) > > > > if (hba->clk_gating.active_reqs || hba->clk_gating.is_suspended || > > hba->ufshcd_state != UFSHCD_STATE_OPERATIONAL || > > - ufshcd_any_tag_in_use(hba) || hba->outstanding_tasks || > > + hba->outstanding_tasks || > > hba->active_uic_cmd || hba->uic_async_done) > > return;
Re: [PATCH 0/2] ARM: dts: Enable ramoops for Rainier and Tacoma
On Fri, 16 Oct 2020 at 04:36, Andrew Jeffery wrote: > > Hi, > > We're looking to improve our crash data capture for the BMC on some IBM > platforms. This small series enables ramoops for Rainier and Tacoma. > > Please review. Reviewed-by: Joel Stanley > > Andrew > > Andrew Jeffery (2): > ARM: dts: rainier: Add reserved memory for ramoops > ARM: dts: tacoma: Add reserved memory for ramoops > > arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts | 9 + > arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts | 9 + > 2 files changed, 18 insertions(+) > > -- > 2.25.1 >
Re: [PATCH v2 1/4] block: keyslot-manager: Introduce passthrough keyslot manager
On Fri, Oct 16, 2020 at 08:20:44AM +0100, Christoph Hellwig wrote: > And this just validates my argument that calling the inline crypto work > directly from the block layer instead of just down below in blk-mq was > wrong. We should not require any support from stacking drivers at the > keyslot manager level. I'm not sure what you're referring to here; could you clarify? It's true that device-mapper devices don't need the actual keyslot management. But they do need the ability to expose crypto capabilities as well as a key eviction function. And those are currently handled by "struct blk_keyslot_manager". Hence the need for a "passthrough keyslot manager" that does those other things but not the actual keyslot management. FWIW, I suggested splitting these up, but you disagreed and said you wanted the crypto capabilities to remain part of the blk_keyslot_manager (https://lkml.kernel.org/linux-block/20200327170047.ga24...@infradead.org/). If you've now changed your mind, please be clear about it. - Eric
Re: [PATCH v2 1/5] scsi: ufs: atomic update for clkgating_enable
On 10/21, Can Guo wrote:
> On 2020-10-21 03:52, Jaegeuk Kim wrote:
> > From: Jaegeuk Kim
> >
> > When giving a stress test which enables/disables clkgating, we hit
> > device
> > timeout sometimes. This patch avoids subtle racy condition to address
> > it.
> >
> > Cc: Alim Akhtar
> > Cc: Avri Altman
> > Cc: Can Guo
> > Signed-off-by: Jaegeuk Kim
>
> Reviewed-by: Can Guo
>
> Next time can you have a cover letter in case of multiple patches?
Ah, it seems I had to cc you here as well.
https://lore.kernel.org/linux-scsi/20201020195258.2005605-1-jaeg...@kernel.org/T/#mb4e43f3bd03a6b7bc136bea21ac805041c1417a2
>
> Thanks,
>
> Can Guo.
>
> > ---
> > drivers/scsi/ufs/ufshcd.c | 12 ++--
> > 1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> > index b8f573a02713..7344353a9167 100644
> > --- a/drivers/scsi/ufs/ufshcd.c
> > +++ b/drivers/scsi/ufs/ufshcd.c
> > @@ -1807,19 +1807,19 @@ static ssize_t
> > ufshcd_clkgate_enable_store(struct device *dev,
> > return -EINVAL;
> >
> > value = !!value;
> > +
> > + spin_lock_irqsave(hba->host->host_lock, flags);
> > if (value == hba->clk_gating.is_enabled)
> > goto out;
> >
> > - if (value) {
> > - ufshcd_release(hba);
> > - } else {
> > - spin_lock_irqsave(hba->host->host_lock, flags);
> > + if (value)
> > + __ufshcd_release(hba);
> > + else
> > hba->clk_gating.active_reqs++;
> > - spin_unlock_irqrestore(hba->host->host_lock, flags);
> > - }
> >
> > hba->clk_gating.is_enabled = value;
> > out:
> > + spin_unlock_irqrestore(hba->host->host_lock, flags);
> > return count;
> > }
Re: [f2fs-dev] [PATCH] f2fs: add compr_inode and compr_blocks sysfs nodes
On Fri, Oct 16, 2020 at 02:14:55PM +0900, Daeho Jeong wrote: > From: Daeho Jeong > > Added compr_inode to show compressed inode count and compr_blocks to > show compressed block count in sysfs. > > Signed-off-by: Daeho Jeong > --- > Documentation/ABI/testing/sysfs-fs-f2fs | 10 ++ > fs/f2fs/sysfs.c | 17 + > 2 files changed, 27 insertions(+) > > diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs > b/Documentation/ABI/testing/sysfs-fs-f2fs > index 834d0becae6d..a01c26484c69 100644 > --- a/Documentation/ABI/testing/sysfs-fs-f2fs > +++ b/Documentation/ABI/testing/sysfs-fs-f2fs > @@ -350,3 +350,13 @@ Date:April 2020 > Contact: "Daeho Jeong" > Description: Give a way to change iostat_period time. 3secs by default. > The new iostat trace gives stats gap given the period. > + > +What:/sys/fs/f2fs//compr_inode > +Date:October 2020 > +Contact: "Daeho Jeong" > +Description: Show compressed inode count > + > +What:/sys/fs/f2fs//compr_blocks > +Date:October 2020 > +Contact: "Daeho Jeong" > +Description: Show compressed block count Is it the count in memory, or on disk? - Eric
RE: [PATCH] scsi: ufs: make sure scan sequence for multiple hosts
Hi, > -Original Message- > From: Bart Van Assche > Sent: Wednesday, October 21, 2020 12:15 PM > To: Chanho Park ; j...@linux.ibm.com; > martin.peter...@oracle.com > Cc: alim.akh...@samsung.com; avri.alt...@wdc.com; linux- > s...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH] scsi: ufs: make sure scan sequence for multiple hosts > > On 10/20/20 12:05 AM, Chanho Park wrote: > > By doing scan as asynchronous way, scsi device scannning can be out of > > order execution. It is no problem if there is a ufs host but the scsi > > device name of each host can be changed according to the scan sequences. > > > > Ideal Case) host0 scan first > > host0 will be started from /dev/sda > > -> /dev/sdb (BootLUN0 of host0) > > -> /dev/sdc (BootLUN1 of host1) > > host1 will be started from /dev/sdd > > > > This might be an ideal case and we can easily find the host device by > > this mappinng. > > > > However, Abnormal Case) host1 scan first, > > host1 will be started from /dev/sda and host0 will be followed later. > > > > To make sure the scan sequences according to the host, we can use a > > bitmap which hosts are scanned and wait until previous hosts are > > finished to scan. > > This sounds completely wrong to me. No code should depend on the order in > which LUNs are scanned. Please use the soft links created by udev instead > of serializing LUN scanning. > Thanks for your review. Did you mean /dev/disk/by-[part]label/ symlink? It's quite reasonable to use them by udev in userspace such as initramfs but some cases does not use initramfs or initrd. In that case, we need to load the root device(/dev/sda[N]) directly from kernel. Anyway, scsi disk(sd) case, the scan order will not be changed until the port has changed so they'll have permanent device names. I'd like to make permanent UFS device names. Best Regards, Chanho Park <>
Re: [PATCH] arm64: NUMA: Kconfig: Increase max number of nodes
On 10/20/2020 11:39 PM, Valentin Schneider wrote: > > Hi, > > Nit on the subject: this only increases the default, the max is still 2¹⁰. Agreed. > > On 20/10/20 18:34, Vanshidhar Konda wrote: >> The current arm64 max NUMA nodes default to 4. Today's arm64 systems can >> reach or exceed 16. Increase the number to 64 (matching x86_64). >> >> Signed-off-by: Vanshidhar Konda >> --- >> arch/arm64/Kconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >> index 893130ce1626..3e69d3c981be 100644 >> --- a/arch/arm64/Kconfig >> +++ b/arch/arm64/Kconfig >> @@ -980,7 +980,7 @@ config NUMA >> config NODES_SHIFT >> int "Maximum NUMA Nodes (as a power of 2)" >> range 1 10 >> -default "2" >> +default "6" > > This leads to more statically allocated memory for things like node to CPU > maps (see uses of MAX_NUMNODES), but that shouldn't be too much of an > issue. The smaller systems should not be required to waste those memory in a default case, unless there is a real and available larger system with those increased nodes. > > AIUI this also directly correlates to how many more page->flags bits are > required: are we sure the max 10 works on any aarch64 platform? I'm We will have to test that. Besides 256 (2 ^ 8) is the first threshold to be crossed here. > genuinely asking here, given that I'm mostly a stranger to the mm > world. The default should be something we're somewhat confident works > everywhere. Agreed. Do we really need to match X86 right now ? Do we really have systems that has 64 nodes ? We should not increase the default node value and then try to solve some new problems, when there might not be any system which could even use that. I would suggest increase NODES_SHIFT value upto as required by a real and available system. > >> depends on NEED_MULTIPLE_NODES >> help >> Specify the maximum number of NUMA Nodes available on the target >
linux-next: Tree for Oct 21
Hi all, Since the merge window is open, please do not add any v5.11 material to your linux-next included branches until after v5.10-rc1 has been released. Changes since 20201016: The ext4 tree gained a conflict against Linus' tree. The pm tree gained a conflict against the arm-soc tree. The rpmsg tree lost its build failure. The notifications tree gained conflicts against Linus' tree. Non-merge commits (relative to Linus' tree): 2526 2790 files changed, 354749 insertions(+), 44466 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig and htmldocs. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 329 trees (counting Linus' and 86 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (38525c6919e2 Merge tag 'for-v5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply) Merging fixes/fixes (9123e3a74ec7 Linux 5.9-rc1) Merging kbuild-current/fixes (e30d694c3381 Documentation/llvm: Fix clang target examples) Merging arc-current/for-curr (6364d1b41cc3 arc: include/asm: fix typos of "themselves") Merging arm-current/fixes (9123e3a74ec7 Linux 5.9-rc1) Merging arm64-fixes/for-next/fixes (39e4716caa59 crypto: arm64: Use x16 with indirect branch to bti_c) Merging arm-soc-fixes/arm/fixes (6869f774b1cd Merge tag 'omap-for-v5.9/fixes-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes) Merging uniphier-fixes/fixes (48778464bb7d Linux 5.8-rc2) Merging drivers-memory-fixes/fixes (7ff3a2a626f7 memory: jz4780_nemc: Fix an error pointer vs NULL check in probe()) Merging m68k-current/for-linus (50c5feeea0af ide/macide: Convert Mac IDE driver to platform driver) Merging powerpc-fixes/fixes (d1781f237047 selftests/powerpc: Make alignment handler test P9N DD2.1 vector CI load workaround) Merging s390-fixes/fixes (549738f15da0 Linux 5.9-rc8) Merging sparc/master (0a95a6d1a4cd sparc: use for_each_child_of_node() macro) Merging fscrypt-current/for-stable (2b4eae95c736 fscrypt: don't evict dirty inodes after removing key) Merging net/master (618355cc6a0d nfc: remove unneeded break) Merging bpf/master (8568c3cefd51 bpf: selftest: Ensure the return value of the bpf_per_cpu_ptr() must be checked) Merging ipsec/master (7fe94612dd4c xfrm: interface: fix the priorities for ipip and ipv6 tunnels) Merging netfilter/master (31cc578ae2de netfilter: nftables_offload: KASAN slab-out-of-bounds Read in nft_flow_rule_create) Merging ipvs/master (48d072c4e8cd selftests: netfilter: add time counter check) Merging wireless-drivers/master (df41c19abbea drivers/net/wan/hdlc_fr: Move the skb_headroom check out of fr_hard_header) Merging mac80211/master (9ff9b0d392ea Merge tag 'net-next-5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next) Merging rdma-fixes/for-rc (a1b8638ba132 Linux 5.9-rc7) Merging sound-current/for-linus (7da4c510abff ALSA: usb-audio: Line6 Pod Go interface requires static clock rate quirk) Merging sound-asoc-fixes/for-linus (8101e3024d76 Merge remote-tracking branch 'asoc/for-5.10' into asoc-linus) Merging regmap-fixes/for-linus (549738f15da0 Linux 5.9-rc8) Merging regulator-fixes/for-linus (b7c11f48ff81 Merge remote-tracking branch 'regulator/for-5.10' into regulator-linus) Merging spi-fixes/for-linus (d4f3a651ab82 Merge remote-tracking branch 'spi/for-5.9' into spi-linus) Merging pci-current/fo
Re: [PATCH v2] Documentation: kunit: Update Kconfig parts for KUNIT's module support
On Tue, Oct 13, 2020 at 2:38 PM 'SeongJae Park' via KUnit Development
wrote:
>
> From: SeongJae Park
>
> If 'CONFIG_KUNIT=m', letting kunit tests that do not support loadable
> module build depends on 'KUNIT' instead of 'KUNIT=y' result in compile
> errors. This commit updates the document for this.
>
> Fixes: 9fe124bf1b77 ("kunit: allow kunit to be loaded as a module")
> Signed-off-by: SeongJae Park
Sorry for the delay in looking at this. Apart from another minuscule
typo below, this looks good to me.
Reviewed-by: David Gow
Cheers,
-- David
> ---
>
> Changes from v1
> (https://lore.kernel.org/linux-kselftest/20201012105420.5945-1-sjp...@amazon.com/):
> - Fix a typo (Marco Elver)
>
> ---
> Documentation/dev-tools/kunit/start.rst | 2 +-
> Documentation/dev-tools/kunit/usage.rst | 5 +
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/dev-tools/kunit/start.rst
> b/Documentation/dev-tools/kunit/start.rst
> index d23385e3e159..454f307813ea 100644
> --- a/Documentation/dev-tools/kunit/start.rst
> +++ b/Documentation/dev-tools/kunit/start.rst
> @@ -197,7 +197,7 @@ Now add the following to ``drivers/misc/Kconfig``:
>
> config MISC_EXAMPLE_TEST
> bool "Test for my example"
> - depends on MISC_EXAMPLE && KUNIT
> + depends on MISC_EXAMPLE && KUNIT=y
>
> and the following to ``drivers/misc/Makefile``:
>
> diff --git a/Documentation/dev-tools/kunit/usage.rst
> b/Documentation/dev-tools/kunit/usage.rst
> index 3c3fe8b5fecc..b331f5a5b0b9 100644
> --- a/Documentation/dev-tools/kunit/usage.rst
> +++ b/Documentation/dev-tools/kunit/usage.rst
> @@ -556,6 +556,11 @@ Once the kernel is built and installed, a simple
>
> ...will run the tests.
>
> +.. note::
> + Note that you should make your test depends on ``KUNIT=y`` in Kconfig if
> the
nit: Grammatically, this should technically be either "depend" (2nd
person), or something like "make sure [that] your test depends".
> + test does not support module build. Otherwise, it will trigger compile
> + errors if ``CONFIG_KUNIT`` is ``m``.
> +
Someday it'd be nice to better discuss the reasons a test suite might
not be compilable as a module. It's probably outside the scope of this
commit to do it properly, though.
> Writing new tests for other architectures
> -
>
> --
> 2.17.1
>
> --
> You received this message because you are subscribed to the Google Groups
> "KUnit Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kunit-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/kunit-dev/20201013063743.32179-1-sjpark%40amazon.com.
Re: [PATCH] net: dsa: bcm_sf2: make const array static, makes object smaller
On Tue, 20 Oct 2020 09:51:39 -0700 Florian Fainelli wrote: > On 10/20/20 9:50 AM, Colin King wrote: > > From: Colin Ian King > > > > Don't populate the const array rate_table on the stack but instead it > > static. Makes the object code smaller by 46 bytes. > > > > Before: > >textdata bss dec hex filename > > 298123824 192 338288424 drivers/net/dsa/bcm_sf2.o > > > > After: > >textdata bss dec hex filename > > 296703920 192 3378283f6 drivers/net/dsa/bcm_sf2.o > > > > (gcc version 10.2.0) > > > > Signed-off-by: Colin Ian King > > Acked-by: Florian Fainelli Applied, thanks!
Re: [PATCH] mptcp: MPTCP_IPV6 should depend on IPV6 instead of selecting it
On Tue, 20 Oct 2020 11:26:34 +0200 Matthieu Baerts wrote: > On 20/10/2020 09:38, Geert Uytterhoeven wrote: > > MPTCP_IPV6 selects IPV6, thus enabling an optional feature the user may > > not want to enable. Fix this by making MPTCP_IPV6 depend on IPV6, like > > is done for all other IPv6 features. > > Here again, the intension was to select IPv6 from MPTCP but I understand > the issue: if we enable MPTCP, we will select IPV6 as well by default. > Maybe not what we want on some embedded devices with very limited memory > where IPV6 is already off. We should instead enable MPTCP_IPV6 only if > IPV6=y. LGTM then! > > Reviewed-by: Matthieu Baerts Applied, thanks!
Re: [PATCH v2 09/14] perf arm-spe: Refactor counter packet handling
On Tue, Oct 20, 2020 at 10:53:47PM +0100, André Przywara wrote:
> On 29/09/2020 14:39, Leo Yan wrote:
>
> Hi,
>
> > This patch defines macros for counter packet header, and uses macro to
> > replace hard code values for packet parsing.
> >
> > Signed-off-by: Leo Yan
> > ---
> > .../util/arm-spe-decoder/arm-spe-pkt-decoder.c | 17 ++---
> > .../util/arm-spe-decoder/arm-spe-pkt-decoder.h | 9 +
> > 2 files changed, 19 insertions(+), 7 deletions(-)
> >
> > diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > index 00a2cd1af422..ed0f4c74dfc5 100644
> > --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > @@ -150,10 +150,13 @@ static int arm_spe_get_counter(const unsigned char
> > *buf, size_t len,
> >const unsigned char ext_hdr, struct arm_spe_pkt
> > *packet)
> > {
> > packet->type = ARM_SPE_COUNTER;
> > - if (ext_hdr)
> > - packet->index = ((buf[0] & 0x3) << 3) | (buf[1] & 0x7);
> > - else
> > - packet->index = buf[0] & 0x7;
> > + if (ext_hdr) {
> > + packet->index = (buf[1] & SPE_CNT_PKT_HDR_INDEX_MASK);
> > + packet->index |= ((buf[0] & SPE_CNT_PKT_HDR_EXT_INDEX_MASK)
> > + << SPE_CNT_PKT_HDR_EXT_INDEX_SHIFT);
> > + } else {
> > + packet->index = buf[0] & SPE_CNT_PKT_HDR_INDEX_MASK;
>
> That looks suspiciously similar to the extended header in the address
> packet. Can you use the same name for that?
Checked for counter packet and address packet, they are using the same
format for index. Will use the same name.
> And, similar to the address packet, what about:
> packet->index |= SPE_PKT_EXT_HEADER_INDEX(buf[0]);
Will do.
> (merging the mask and the shift in the macro definition)
>
> > + }
> >
> > return arm_spe_get_payload(buf, len, ext_hdr, packet);
> > }
> > @@ -431,17 +434,17 @@ int arm_spe_pkt_desc(const struct arm_spe_pkt
> > *packet, char *buf,
> > return ret;
> >
> > switch (idx) {
> > - case 0:
> > + case SPE_CNT_PKT_HDR_INDEX_TOTAL_LAT:
> > ret = arm_spe_pkt_snprintf(&buf, &blen, "TOT");
> > if (ret < 0)
> > return ret;
> > break;
> > - case 1:
> > + case SPE_CNT_PKT_HDR_INDEX_ISSUE_LAT:
> > ret = arm_spe_pkt_snprintf(&buf, &blen, "ISSUE");
> > if (ret < 0)
> > return ret;
> > break;
> > - case 2:
> > + case SPE_CNT_PKT_HDR_INDEX_TRANS_LAT:
> > ret = arm_spe_pkt_snprintf(&buf, &blen, "XLAT");
> > if (ret < 0)
> > return ret;
> > diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> > b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> > index 62db4ff91832..18667a63f5ba 100644
> > --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> > +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> > @@ -89,6 +89,15 @@ struct arm_spe_pkt {
> > /* Context packet header */
> > #define SPE_CTX_PKT_HDR_INDEX_MASK GENMASK_ULL(1, 0)
> >
> > +/* Counter packet header */
> > +#define SPE_CNT_PKT_HDR_INDEX_MASK GENMASK_ULL(2, 0)
> > +#define SPE_CNT_PKT_HDR_INDEX_TOTAL_LAT(0x0)
> > +#define SPE_CNT_PKT_HDR_INDEX_ISSUE_LAT(0x1)
> > +#define SPE_CNT_PKT_HDR_INDEX_TRANS_LAT(0x2)
>
> I think the Linux kernel coding style does not mention parentheses just
> around numbers, so just 0x2 would suffice, for instance.
> See section 12) in Documentation/process/coding-style.rst
Yeah, it gives example as "#define CONSTANT 0x4000"; will follow the
coding style.
Thanks for suggestions!
Leo
Re: [PATCH v7 2/4] powerpc: Refactor kexec functions to move arch independent code to ima
Hi Lakshmi, On Tue, 2020-10-20 at 19:38 -0700, Lakshmi Ramasubramanian wrote: > On 10/20/20 1:01 PM, Mimi Zohar wrote: > > On Wed, 2020-09-30 at 13:59 -0700, Lakshmi Ramasubramanian wrote: > >> The functions ima_get_kexec_buffer() and ima_free_kexec_buffer(), > >> that handle carrying forward the IMA measurement logs on kexec for > >> powerpc do not have architecture specific code, but they are currently > >> defined for powerpc only. > >> > >> Move ima_get_kexec_buffer() and ima_free_kexec_buffer() to IMA > >> subsystem. A later patch in this series will use these functions for > >> carrying forward the IMA measurement log for ARM64. > >> > >> With the above refactoring arch/powerpc/kexec/ima.c contains only > >> functions used when CONFIG_IMA_KEXEC is enabled. Update Makefile > >> in arch/powerpc/kexec to include arch/powerpc/kexec/ima.c only > >> when CONFIG_IMA_KEXEC is enabled. > >> > >> Move ima_dump_measurement_list() and ima_add_kexec_buffer() to > >> a new file namely ima_kexec_fdt.c in IMA. Update > >> security/integrity/ima/Makefile to include ima_kexec_fdt.c only > >> when CONFIG_IMA_KEXEC is enabled. > >> > >> Co-developed-by: Prakhar Srivastava > >> Signed-off-by: Prakhar Srivastava > >> Signed-off-by: Lakshmi Ramasubramanian > > > > The existing support for carrying the IMA measurement list across kexec > > is limited to powerpc. This patch set is adding similar support for > > arm64, making as much of the existing code as generic as possible. > > However ima_dump_measurement_list() is already generic, but for some > > reason this patch moves it to ima_kexec_fdt.c. ima_kexec_fdt.c should > > be limited to device tree specific code. > > I wanted to split the functions defined under CONFIG_HAVE_IMA_KEXEC and > CONFIG_IMA_KEXEC to separate files so that we can get rid of #ifdef in C > file and instead conditionally compile the C files (using Makefile). > > ima_dump_measurement_list() need to be defined only when > CONFIG_IMA_KEXEC is defined. I moved it to ima_kexec_fdt.c In this case, everything in ima_kexec.c relates to carrying or restoring the measurement list. It's a logical unit. Separating them doesn't make sense. > > Instead of ima_kexec_fdt.c, where ima_dump_measurement_list() and > ima_add_kexec_buffer() are defined, perhaps I can change the file name > to "ima_kexec_buffer.c". Would that be better? I don't understand why adding support for carrying the IMA measurement across kexec on ARM64, should require any changes in the IMA loading and restoring the measurement list code itself. Please minimize the changes. thanks, Mimi
Re: [PATCH v2] fat: Add KUnit tests for checksums and timestamps
On Tue, Oct 20, 2020 at 2:51 PM OGAWA Hirofumi wrote: > > David Gow writes: > > > diff --git a/fs/fat/misc.c b/fs/fat/misc.c > > index f1b2a1fc2a6a..445ad3542e74 100644 > > --- a/fs/fat/misc.c > > +++ b/fs/fat/misc.c > > @@ -229,6 +229,7 @@ void fat_time_fat2unix(struct msdos_sb_info *sbi, > > struct timespec64 *ts, > > ts->tv_nsec = 0; > > } > > } > > +EXPORT_SYMBOL_GPL(fat_time_fat2unix); > > Hm, can this export only if FAT_KUNIT_TEST is builtin or module (maybe > #if IS_ENABLED(...))? And #if will also be worked as the comment too. > That's possible, but I'd prefer to export it unconditionally for two reasons: 1. It'd make it possible to build the fat_test module without having to rebuild the whole kernel/fat. 2. It'd be consistent with fat_time_unix2fat(), which is exported for use in vfat/msdos anyway. Neither of those are dealbreakers, though, so if you'd still prefer this to be behind an ifdef, I'll change it. -- David
[tip:timers/urgent] BUILD SUCCESS a4fd8414659bf470e2146b352574bbd274e54b7a
-64bit_defconfig armmps2_defconfig arm omap2plus_defconfig powerpc acadia_defconfig arm mainstone_defconfig mipsmalta_qemu_32r6_defconfig powerpc g5_defconfig powerpc tqm8555_defconfig xtensa virt_defconfig arm eseries_pxa_defconfig shtitan_defconfig arm assabet_defconfig shmigor_defconfig ia64 alldefconfig armvt8500_v6_v7_defconfig openriscdefconfig mips malta_defconfig xtensaxip_kc705_defconfig m68k amiga_defconfig arc nsimosci_hs_defconfig mips cavium_octeon_defconfig sh polaris_defconfig arm am200epdkit_defconfig mipsnlm_xlr_defconfig arm integrator_defconfig sh alldefconfig powerpc cm5200_defconfig arm vf610m4_defconfig mips rt305x_defconfig m68k m5249evb_defconfig xtensa iss_defconfig powerpc mpc866_ads_defconfig ia64generic_defconfig arm versatile_defconfig powerpccell_defconfig sh lboxre2_defconfig arm pxa3xx_defconfig nios2alldefconfig powerpc mpc8560_ads_defconfig arm s3c6400_defconfig powerpc sequoia_defconfig armoxnas_v6_defconfig sh rsk7201_defconfig armzeus_defconfig xtensa cadence_csp_defconfig arc allyesconfig mips ip27_defconfig m68kmac_defconfig mips tb0226_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a001-20201021 x86_64 randconfig-a002-20201021 x86_64 randconfig-a003-20201021 x86_64 randconfig-a006-20201021 x86_64 randconfig-a005-20201021 x86_64 randconfig-a004-20201021 i386 randconfig-a002-20201020 i386 randconfig-a005-20201020 i386 randconfig-a003-20201020 i386 randconfig-a001-20201020 i386 randconfig-a006-20201020 i386 randconfig-a004-20201020 i386 randconfig-a002-20201021 i386 randconfig-a005-20201021 i386 randconfig-a003-20201021 i386 randconfig-a001-20201021 i386 randconfig-a006-20201021 i386 randconfig-a004-20201021 x86_64 randconfig-a011-20201020 x86_64 randconfig-a013-20201020 x86_64 randconfig-a016-20201020 x86_64 randconfig-a015-20201020 x86_64 randconfig-a012-20201020 x86_64 randconfig-a014-20201020 i386 randconfig-a016-20201020 i386 randconfig-a014-20201020 i386 randconfig-a015-20201020 i386 randconfig-a013-20201020 i386 randconfig-a012-20201020 i386 randconfig-a011-20201020 i386 randconfig-a016-20201021 i386
Re: [PATCH] lib: add basic KUnit test for lib/math
On Tue, Oct 20, 2020 at 6:46 AM Daniel Latypov wrote:
>
> Add basic test coverage for files that don't require any config options:
> * gcd.c
> * lcm.c
> * int_sqrt.c
> * reciprocal_div.c
> (Ignored int_pow.c since it's a simple textbook algorithm.)
>
I don't see a particular reason why int_pow.c being a simple algorithm
means it shouldn't be tested. I'm not saying it has to be tested by
this particular change -- and I doubt the test would be
earth-shatteringly interesting -- but there's no real reason against
testing it.
> These tests aren't particularly interesting, but
> * they're chosen as easy to understand examples of how to write tests
> * provides a place to add tests for any new files in this dir
> * written so adding new test cases to cover edge cases should be easy
I think these tests can stand on their own merits, rather than just as
examples (though I do think they do make good additional examples for
how to test these sorts of functions).
So, I'd treat this as an actual test of the maths functions (and
you've got what seems to me a decent set of test cases for that,
though there are a couple of comments below) first, and any use it
gains as an example is sort-of secondary to that (anything that makes
it a better example is likely to make it a better test anyway).
In any case, modulo the comments below, this seems good to me.
-- David
> Signed-off-by: Daniel Latypov
> ---
> lib/math/Kconfig | 5 ++
> lib/math/Makefile| 2 +
> lib/math/math_test.c | 197 +++
> 3 files changed, 204 insertions(+)
> create mode 100644 lib/math/math_test.c
>
> diff --git a/lib/math/Kconfig b/lib/math/Kconfig
> index f19bc9734fa7..6ba8680439c1 100644
> --- a/lib/math/Kconfig
> +++ b/lib/math/Kconfig
> @@ -15,3 +15,8 @@ config PRIME_NUMBERS
>
> config RATIONAL
> bool
> +
> +config MATH_KUNIT_TEST
> + tristate "KUnit test for lib/math" if !KUNIT_ALL_TESTS
> + default KUNIT_ALL_TESTS
> + depends on KUNIT
> diff --git a/lib/math/Makefile b/lib/math/Makefile
> index be6909e943bd..fba6fe90f50b 100644
> --- a/lib/math/Makefile
> +++ b/lib/math/Makefile
> @@ -4,3 +4,5 @@ obj-y += div64.o gcd.o lcm.o int_pow.o int_sqrt.o
> reciprocal_div.o
> obj-$(CONFIG_CORDIC) += cordic.o
> obj-$(CONFIG_PRIME_NUMBERS)+= prime_numbers.o
> obj-$(CONFIG_RATIONAL) += rational.o
> +
> +obj-$(CONFIG_MATH_KUNIT_TEST) += math_test.o
> diff --git a/lib/math/math_test.c b/lib/math/math_test.c
> new file mode 100644
> index ..6f4681ea7c72
> --- /dev/null
> +++ b/lib/math/math_test.c
> @@ -0,0 +1,197 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Simple KUnit suite for math helper funcs that are always enabled.
> + *
> + * Copyright (C) 2020, Google LLC.
> + * Author: Daniel Latypov
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* Generic test case for unsigned long inputs. */
> +struct test_case {
> + unsigned long a, b;
> + unsigned long result;
> +};
> +
> +static void gcd_test(struct kunit *test)
> +{
> + const char *message_fmt = "gcd(%lu, %lu)";
> + int i;
> +
> + struct test_case test_cases[] = {
> + {
> + .a = 0, .b = 1,
> + .result = 1,
> + },
> + {
> + .a = 2, .b = 2,
> + .result = 2,
> + },
> + {
> + .a = 2, .b = 4,
> + .result = 2,
> + },
> + {
> + .a = 3, .b = 5,
> + .result = 1,
> + },
> + {
> + .a = 3*9, .b = 3*5,
> + .result = 3,
> + },
> + {
> + .a = 3*5*7, .b = 3*5*11,
> + .result = 15,
> + },
> + {
> + .a = (1 << 21) - 1,
> + .b = (1 << 22) - 1,
It might be worth noting the factors of these (7^2*127*337 and
3*23*89*683) in a comment.
They aren't mersenne primes, if that's what you were going for, though
they are coprime.
> + .result = 1,
> + },
> + };
> +
> + for (i = 0; i < ARRAY_SIZE(test_cases); ++i) {
> + KUNIT_EXPECT_EQ_MSG(test, test_cases[i].result,
> + gcd(test_cases[i].a, test_cases[i].b),
> + message_fmt, test_cases[i].a,
> + test_cases[i].b);
> +
> + /* gcd(a,b) == gcd(b,a) */
> + KUNIT_EXPECT_EQ_MSG(test, test_cases[i].result,
> + gcd(test_cases[i].b, test_cases[i].a),
> + message_fmt, test_cases[i].b,
> + test_cases[i].a);
> + }
> +}
> +
> +stati
Re: cgroup and FALLOC_FL_PUNCH_HOLE: WARNING: CPU: 13 PID: 2438 at mm/page_counter.c:57 page_counter_uncharge+0x4b/0x5
On 10/20/20 6:38 AM, David Hildenbrand wrote:
>
> I'm bisecting the warning right now. Looks like it was introduced in v5.7.
I found the following bugs in the cgroup reservation accounting. The ones
in region_del are pretty obvious as the number of pages to uncharge would
always be zero. The one on alloc_huge_page needs racing code to expose.
With these fixes, my testing is showing consistent/correct results for
hugetlb reservation cgroup accounting.
It would be good if Mina (at least) would look these over. Would also
be interesting to know if these fixes address the bug seen with the qemu
use case.
I'm still doing more testing and code inspection to look for other issues.
>From 861bcd7d0443f18a5fed3c3ddc5f1c71e78c4ef4 Mon Sep 17 00:00:00 2001
From: Mike Kravetz
Date: Tue, 20 Oct 2020 20:21:42 -0700
Subject: [PATCH] hugetlb_cgroup: fix reservation accounting
Signed-off-by: Mike Kravetz
---
mm/hugetlb.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 67fc6383995b..c92366313780 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -685,17 +685,17 @@ static long region_del(struct resv_map *resv, long f,
long t)
}
if (f <= rg->from) {/* Trim beginning of region */
- del += t - rg->from;
- rg->from = t;
-
hugetlb_cgroup_uncharge_file_region(resv, rg,
t - rg->from);
- } else {/* Trim end of region */
- del += rg->to - f;
- rg->to = f;
+ del += t - rg->from;
+ rg->from = t;
+ } else {/* Trim end of region */
hugetlb_cgroup_uncharge_file_region(resv, rg,
rg->to - f);
+
+ del += rg->to - f;
+ rg->to = f;
}
}
@@ -2454,6 +2454,9 @@ struct page *alloc_huge_page(struct vm_area_struct *vma,
rsv_adjust = hugepage_subpool_put_pages(spool, 1);
hugetlb_acct_memory(h, -rsv_adjust);
+ if (deferred_reserve)
+ hugetlb_cgroup_uncharge_page_rsvd(hstate_index(h),
+ pages_per_huge_page(h), page);
}
return page;
--
2.25.4
Re: [PATCH] net: ftgmac100: Ensure tx descriptor updates are visible
On Wed, 21 Oct 2020 at 00:00, Benjamin Herrenschmidt
wrote:
>
> On Wed, 2020-10-21 at 08:36 +1030, Joel Stanley wrote:
> > We must ensure the tx descriptor updates are visible before updating
> > the tx pointer.
> >
> > This resolves the tx hangs observed on the 2600 when running iperf:
>
> To clarify the comment here. This doesn't ensure they are visible to
> the hardware but to other CPUs. This is the ordering vs start_xmit and
> tx_complete.
Thanks. Let me know if this makes sense, or if I'm completely off the mark.
How is this for the commit message:
This resolves the tx hangs observed on the 2600 when running iperf.
This is ensuring the setting of the OWN bit in txdes0 of the
descriptor is visible to other CPUs before updating the pointer. Doing
this provides ordering between start_xmit and tx_complete.
and then I'll put:
/* Ensure the descriptor config is visible to other CPUs before setting
* the tx pointer. This ensures ordering against start_xmit which checks
* the OWN bit before proceeding.
*/
and similar for tx_complete?
>
> Cheers,
> Ben.
>
> > root@ast2600:~# iperf3 -c 192.168.86.146 -R
> > Connecting to host 192.168.86.146, port 5201
> > Reverse mode, remote host 192.168.86.146 is sending
> > [ 5] local 192.168.86.173 port 43886 connected to 192.168.86.146
> > port 5201
> > [ ID] Interval Transfer Bitrate
> > [ 5] 0.00-1.00 sec 90.7 MBytes 760 Mbits/sec
> > [ 5] 1.00-2.00 sec 91.7 MBytes 769 Mbits/sec
> > [ 5] 2.00-3.00 sec 91.7 MBytes 770 Mbits/sec
> > [ 5] 3.00-4.00 sec 91.7 MBytes 769 Mbits/sec
> > [ 5] 4.00-5.00 sec 91.8 MBytes 771 Mbits/sec
> > [ 5] 5.00-6.00 sec 91.8 MBytes 771 Mbits/sec
> > [ 5] 6.00-7.00 sec 91.9 MBytes 771 Mbits/sec
> > [ 5] 7.00-8.00 sec 91.4 MBytes 767 Mbits/sec
> > [ 5] 8.00-9.00 sec 91.3 MBytes 766 Mbits/sec
> > [ 5] 9.00-10.00 sec 91.9 MBytes 771 Mbits/sec
> > [ 5] 10.00-11.00 sec 91.8 MBytes 770 Mbits/sec
> > [ 5] 11.00-12.00 sec 91.8 MBytes 770 Mbits/sec
> > [ 5] 12.00-13.00 sec 90.6 MBytes 761 Mbits/sec
> > [ 5] 13.00-14.00 sec 45.2 KBytes 370 Kbits/sec
> > [ 5] 14.00-15.00 sec 0.00 Bytes 0.00 bits/sec
> > [ 5] 15.00-16.00 sec 0.00 Bytes 0.00 bits/sec
> > [ 5] 16.00-17.00 sec 0.00 Bytes 0.00 bits/sec
> > [ 5] 17.00-18.00 sec 0.00 Bytes 0.00 bits/sec
> > [ 67.031671] [ cut here ]
> > [ 67.036870] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:442
> > dev_watchdog+0x2dc/0x300
> > [ 67.046123] NETDEV WATCHDOG: eth2 (ftgmac100): transmit queue 0
> > timed out
> >
> > Fixes: 52c0cae87465 ("ftgmac100: Remove tx descriptor accessors")
> > Signed-off-by: Joel Stanley
> > ---
> > drivers/net/ethernet/faraday/ftgmac100.c | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/faraday/ftgmac100.c
> > b/drivers/net/ethernet/faraday/ftgmac100.c
> > index 331d4bdd4a67..15cdfeb135b0 100644
> > --- a/drivers/net/ethernet/faraday/ftgmac100.c
> > +++ b/drivers/net/ethernet/faraday/ftgmac100.c
> > @@ -653,6 +653,11 @@ static bool ftgmac100_tx_complete_packet(struct
> > ftgmac100 *priv)
> > ftgmac100_free_tx_packet(priv, pointer, skb, txdes, ctl_stat);
> > txdes->txdes0 = cpu_to_le32(ctl_stat & priv-
> > >txdes0_edotr_mask);
> >
> > + /* Ensure the descriptor config is visible before setting the
> > tx
> > + * pointer.
> > + */
> > + smp_wmb();
> > +
> > priv->tx_clean_pointer = ftgmac100_next_tx_pointer(priv,
> > pointer);
> >
> > return true;
> > @@ -806,6 +811,11 @@ static netdev_tx_t
> > ftgmac100_hard_start_xmit(struct sk_buff *skb,
> > dma_wmb();
> > first->txdes0 = cpu_to_le32(f_ctl_stat);
> >
> > + /* Ensure the descriptor config is visible before setting the
> > tx
> > + * pointer.
> > + */
> > + smp_wmb();
> > +
> > /* Update next TX pointer */
> > priv->tx_pointer = pointer;
> >
>
[PATCH kernel 0/2] powerpc/dma: Fallback to dma_ops when persistent memory present
This allows mixing direct DMA (to/from RAM) and IOMMU (to/from apersistent memory) on the PPC64/pseries platform. This was supposed to be a single patch but unexpected move of direct DMA functions happened. This is based on sha1 7cf726a59435 Linus Torvalds "Merge tag 'linux-kselftest-kunit-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest". Please comment. Thanks. Alexey Kardashevskiy (2): Revert "dma-mapping: move large parts of to kernel/dma" powerpc/dma: Fallback to dma_ops when persistent memory present include/linux/dma-direct.h | 106 ++ kernel/dma/direct.h| 119 - arch/powerpc/kernel/dma-iommu.c| 68 +- arch/powerpc/platforms/pseries/iommu.c | 41 +++-- kernel/dma/direct.c| 2 +- kernel/dma/mapping.c | 2 +- 6 files changed, 207 insertions(+), 131 deletions(-) delete mode 100644 kernel/dma/direct.h -- 2.17.1
[PATCH kernel 2/2] powerpc/dma: Fallback to dma_ops when persistent memory present
So far we have been using huge DMA windows to map all the RAM available.
The RAM is normally mapped to the VM address space contiguously, and
there is always a reasonable upper limit for possible future hot plugged
RAM which makes it easy to map all RAM via IOMMU.
Now there is persistent memory ("ibm,pmemory" in the FDT) which (unlike
normal RAM) can map anywhere in the VM space beyond the maximum RAM size
and since it can be used for DMA, it requires extending the huge window
up to MAX_PHYSMEM_BITS which requires hypervisor support for:
1. huge TCE tables;
2. multilevel TCE tables;
3. huge IOMMU pages.
Certain hypervisors cannot do either so the only option left is
restricting the huge DMA window to include only RAM and fallback to
the default DMA window for persistent memory.
This checks if the system has persistent memory. If it does not,
the DMA bypass mode is selected, i.e.
* dev->bus_dma_limit = 0
* dev->dma_ops_bypass = true <- this avoid calling dma_ops for mapping.
If there is such memory, this creates identity mapping only for RAM and
disables the DMA bypass mode which makes generic DMA code use indirect
dma_ops which may have performance impact:
* dev->bus_dma_limit = bus_offset + max_ram_size
for example 0x0800..8000. for a 2GB VM
* dev->dma_ops_bypass = false <- this forces indirect calls to dma_ops for
every mapping which then directs these to small or huge window.
This should not change the existing behaviour when no persistent memory.
Signed-off-by: Alexey Kardashevskiy
---
Without reverting 19c65c3d30bb5a97170, I could have added
I can repost if this is preferrable. Thanks.
---
Changelog:
v2:
* rebased on current upstream with the device::bypass added and DMA
direct code movement reverted
---
arch/powerpc/kernel/dma-iommu.c| 68 +-
arch/powerpc/platforms/pseries/iommu.c | 41 +---
2 files changed, 99 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
index a1c744194018..9a2a3b95f72d 100644
--- a/arch/powerpc/kernel/dma-iommu.c
+++ b/arch/powerpc/kernel/dma-iommu.c
@@ -10,6 +10,16 @@
#include
#include
+static inline bool can_map_direct(struct device *dev, phys_addr_t addr)
+{
+ return dev->bus_dma_limit >= phys_to_dma(dev, addr);
+}
+
+static inline bool dma_handle_direct(struct device *dev, dma_addr_t dma_handle)
+{
+ return dma_handle >= dev->archdata.dma_offset;
+}
+
/*
* Generic iommu implementation
*/
@@ -44,6 +54,12 @@ static dma_addr_t dma_iommu_map_page(struct device *dev,
struct page *page,
enum dma_data_direction direction,
unsigned long attrs)
{
+ if (dev->bus_dma_limit &&
+ can_map_direct(dev, (phys_addr_t) page_to_phys(page) +
+ offset + size))
+ return dma_direct_map_page(dev, page, offset, size, direction,
+ attrs);
+
return iommu_map_page(dev, get_iommu_table_base(dev), page, offset,
size, dma_get_mask(dev), direction, attrs);
}
@@ -53,6 +69,12 @@ static void dma_iommu_unmap_page(struct device *dev,
dma_addr_t dma_handle,
size_t size, enum dma_data_direction direction,
unsigned long attrs)
{
+ if (dev->bus_dma_limit &&
+ dma_handle_direct(dev, dma_handle + size)) {
+ dma_direct_unmap_page(dev, dma_handle, size, direction, attrs);
+ return;
+ }
+
iommu_unmap_page(get_iommu_table_base(dev), dma_handle, size, direction,
attrs);
}
@@ -62,6 +84,22 @@ static int dma_iommu_map_sg(struct device *dev, struct
scatterlist *sglist,
int nelems, enum dma_data_direction direction,
unsigned long attrs)
{
+ if (dev->bus_dma_limit) {
+ struct scatterlist *s;
+ bool direct = true;
+ int i;
+
+ for_each_sg(sglist, s, nelems, i) {
+ direct = can_map_direct(dev,
+ sg_phys(s) + s->offset + s->length);
+ if (!direct)
+ break;
+ }
+ if (direct)
+ return dma_direct_map_sg(dev, sglist, nelems, direction,
+attrs);
+ }
+
return ppc_iommu_map_sg(dev, get_iommu_table_base(dev), sglist, nelems,
dma_get_mask(dev), direction, attrs);
}
@@ -70,6 +108,24 @@ static void dma_iommu_unmap_sg(struct device *dev, struct
scatterlist *sglist,
int nelems, enum dma_data_direction direction,
unsigned long attrs)
{
+ if (dev->bus_dma_limit) {
+ struct scatterlist *s;
+ bool direct =
[PATCH kernel 1/2] Revert "dma-mapping: move large parts of to kernel/dma"
This reverts commit 19c65c3d30bb5a97170e425979d2e44ab2096c7d which
was a right move but sadly there is a POWERPC/pseries hardware config
which uses a mixture of direct and IOMMU DMA but bringing this
logic to the generic code won't benefit anybody else. The user of
this revert comes in the next patch.
Signed-off-by: Alexey Kardashevskiy
---
include/linux/dma-direct.h | 106 +
kernel/dma/direct.h| 119 -
kernel/dma/direct.c| 2 +-
kernel/dma/mapping.c | 2 +-
4 files changed, 108 insertions(+), 121 deletions(-)
delete mode 100644 kernel/dma/direct.h
diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index 18aade195884..e388b77e0048 100644
--- a/include/linux/dma-direct.h
+++ b/include/linux/dma-direct.h
@@ -120,8 +120,114 @@ struct page *dma_direct_alloc_pages(struct device *dev,
size_t size,
void dma_direct_free_pages(struct device *dev, size_t size,
struct page *page, dma_addr_t dma_addr,
enum dma_data_direction dir);
+int dma_direct_get_sgtable(struct device *dev, struct sg_table *sgt,
+ void *cpu_addr, dma_addr_t dma_addr, size_t size,
+ unsigned long attrs);
+bool dma_direct_can_mmap(struct device *dev);
+int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
+ void *cpu_addr, dma_addr_t dma_addr, size_t size,
+ unsigned long attrs);
int dma_direct_supported(struct device *dev, u64 mask);
+bool dma_direct_need_sync(struct device *dev, dma_addr_t dma_addr);
+int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl, int nents,
+ enum dma_data_direction dir, unsigned long attrs);
dma_addr_t dma_direct_map_resource(struct device *dev, phys_addr_t paddr,
size_t size, enum dma_data_direction dir, unsigned long attrs);
+size_t dma_direct_max_mapping_size(struct device *dev);
+#if defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE) || \
+defined(CONFIG_SWIOTLB)
+void dma_direct_sync_sg_for_device(struct device *dev, struct scatterlist *sgl,
+ int nents, enum dma_data_direction dir);
+#else
+static inline void dma_direct_sync_sg_for_device(struct device *dev,
+ struct scatterlist *sgl, int nents, enum dma_data_direction dir)
+{
+}
+#endif
+
+#if defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU) || \
+defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU_ALL) || \
+defined(CONFIG_SWIOTLB)
+void dma_direct_unmap_sg(struct device *dev, struct scatterlist *sgl,
+ int nents, enum dma_data_direction dir, unsigned long attrs);
+void dma_direct_sync_sg_for_cpu(struct device *dev,
+ struct scatterlist *sgl, int nents, enum dma_data_direction
dir);
+#else
+static inline void dma_direct_unmap_sg(struct device *dev,
+ struct scatterlist *sgl, int nents, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+}
+static inline void dma_direct_sync_sg_for_cpu(struct device *dev,
+ struct scatterlist *sgl, int nents, enum dma_data_direction dir)
+{
+}
+#endif
+
+static inline void dma_direct_sync_single_for_device(struct device *dev,
+ dma_addr_t addr, size_t size, enum dma_data_direction dir)
+{
+ phys_addr_t paddr = dma_to_phys(dev, addr);
+
+ if (unlikely(is_swiotlb_buffer(paddr)))
+ swiotlb_tbl_sync_single(dev, paddr, size, dir, SYNC_FOR_DEVICE);
+
+ if (!dev_is_dma_coherent(dev))
+ arch_sync_dma_for_device(paddr, size, dir);
+}
+
+static inline void dma_direct_sync_single_for_cpu(struct device *dev,
+ dma_addr_t addr, size_t size, enum dma_data_direction dir)
+{
+ phys_addr_t paddr = dma_to_phys(dev, addr);
+
+ if (!dev_is_dma_coherent(dev)) {
+ arch_sync_dma_for_cpu(paddr, size, dir);
+ arch_sync_dma_for_cpu_all();
+ }
+
+ if (unlikely(is_swiotlb_buffer(paddr)))
+ swiotlb_tbl_sync_single(dev, paddr, size, dir, SYNC_FOR_CPU);
+
+ if (dir == DMA_FROM_DEVICE)
+ arch_dma_mark_clean(paddr, size);
+}
+
+static inline dma_addr_t dma_direct_map_page(struct device *dev,
+ struct page *page, unsigned long offset, size_t size,
+ enum dma_data_direction dir, unsigned long attrs)
+{
+ phys_addr_t phys = page_to_phys(page) + offset;
+ dma_addr_t dma_addr = phys_to_dma(dev, phys);
+
+ if (unlikely(swiotlb_force == SWIOTLB_FORCE))
+ return swiotlb_map(dev, phys, size, dir, attrs);
+
+ if (unlikely(!dma_capable(dev, dma_addr, size, true))) {
+ if (swiotlb_force != SWIOTLB_NO_FORCE)
+ return swiotlb_map(dev, phys, size, dir, attrs);
+
+ dev_WARN_ONCE(dev, 1,
+"DMA addr %pad+%zu overflow (mask %llx, bus limit
%llx).\n",
+&dma_addr, size, *dev->dma_mask,
dev->bus_dma_limit)
Re: [GIT PULL] prandom32 changes for v5.10
Hi Linus, On Tue, Oct 20, 2020 at 04:08:03PM -0700, Linus Torvalds wrote: > On Tue, Oct 20, 2020 at 12:26 PM Amit Klein wrote: > > > > Quick question: is this patch still planned for inclusion in 5.10-rc1? > > It doesn't even build for me, so no. It clearly hasn't been in > linux-next or anything like that. > > Hint: grep for prandom_seed_early. I'm a bit surprised, as it worked for me, but thanks for checking. Given the lack of responses from many participants on these patches, on several occations I feel that this series is really not welcome. Initially I just tried to test and fix Spelvin's patch, but if there's not that much interest in it, or even reluctance, I'd rather stop. If it's just that the current state is ugly with the two PRNGs side by side, I can get back to completely removing the original one as I did in my first series, and propose a larger series. Or if nobody's interested, I'd rather know so that I don't have to put more time on it :-/ Thanks for letting me know, Willy
Re: [PATCH 1/1] kobject: Don't emit change events if not in sysfs
Hi Greg, I was debugging without a live repro and I was told this patch improved behavior but it's only by chance (someone bisected a Dell D6000 dock's displayport issue to this commit and this change seemed to help; udev logs later shows that's not the case). I took another look at device_init_wakeup and I can see that device_set_wakeup_capable does indeed check for device_is_registered before adding the wakeup attributes so the ordering of events I suspected cannot occur. Thanks for pushing back Greg. It made me take a deeper look at an assumption I hadn't challenged. Please consider this patch abandoned. Abhishek On Mon, Oct 19, 2020 at 10:56 PM Greg Kroah-Hartman wrote: > > On Mon, Oct 19, 2020 at 03:32:57PM -0700, Abhishek Pandit-Subedi wrote: > > Add a check to make sure the kobj is created and in sysfs before sending > > a change event notification. Otherwise, udev rules that depend on the > > change notification may find that the path that changed doesn't actually > > exist. > > Why is the user of the kobject trying to emit a uevent before it is > registered? Shouldn't we fix the root problem here instead? Otherwise > the event is still "gone", the caller will not know what to do about it. > > Please fix the root problem here. > > thanks, > > greg k-h
[PATCH] mm: bio_alloc never fails when set GFP_NOIO, GFP_KERNEL
bio_alloc with __GFP_DIRECT_RECLAIM(which is included in GFP_NOIO,
GFP_KERNEL) never fails, as stated in the comments of bio_alloc_bioset.
So we can remove multiple unneeded null checks of bio_alloc and simplify
the code.
We have done it in fs/ext4/readpage.c, fs/ext4/page-io.c, fs/direct-io.c,
and so forth.
Signed-off-by: Xianting Tian
---
mm/page_io.c | 31 +++
1 file changed, 11 insertions(+), 20 deletions(-)
diff --git a/mm/page_io.c b/mm/page_io.c
index e485a6e8a..9215bb356 100644
--- a/mm/page_io.c
+++ b/mm/page_io.c
@@ -30,18 +30,20 @@ static struct bio *get_swap_bio(gfp_t gfp_flags,
struct page *page, bio_end_io_t end_io)
{
struct bio *bio;
+ struct block_device *bdev;
+ /*
+* bio_alloc will _always_ be able to allocate a bio if
+* __GFP_DIRECT_RECLAIM is set, see comments for bio_alloc_bioset().
+*/
bio = bio_alloc(gfp_flags, 1);
- if (bio) {
- struct block_device *bdev;
+ bio->bi_iter.bi_sector = map_swap_page(page, &bdev);
+ bio_set_dev(bio, bdev);
+ bio->bi_iter.bi_sector <<= PAGE_SHIFT - 9;
+ bio->bi_end_io = end_io;
- bio->bi_iter.bi_sector = map_swap_page(page, &bdev);
- bio_set_dev(bio, bdev);
- bio->bi_iter.bi_sector <<= PAGE_SHIFT - 9;
- bio->bi_end_io = end_io;
+ bio_add_page(bio, page, thp_size(page), 0);
- bio_add_page(bio, page, thp_size(page), 0);
- }
return bio;
}
@@ -351,19 +353,13 @@ int __swap_writepage(struct page *page, struct
writeback_control *wbc,
ret = 0;
bio = get_swap_bio(GFP_NOIO, page, end_write_func);
- if (bio == NULL) {
- set_page_dirty(page);
- unlock_page(page);
- ret = -ENOMEM;
- goto out;
- }
bio->bi_opf = REQ_OP_WRITE | REQ_SWAP | wbc_to_write_flags(wbc);
bio_associate_blkg_from_page(bio, page);
count_swpout_vm_event(page);
set_page_writeback(page);
unlock_page(page);
submit_bio(bio);
-out:
+
return ret;
}
@@ -416,11 +412,6 @@ int swap_readpage(struct page *page, bool synchronous)
ret = 0;
bio = get_swap_bio(GFP_KERNEL, page, end_swap_bio_read);
- if (bio == NULL) {
- unlock_page(page);
- ret = -ENOMEM;
- goto out;
- }
disk = bio->bi_disk;
/*
* Keep this task valid during swap readpage because the oom killer may
--
2.17.1
Re: [PATCH v7 1/4] KEYS: trusted: Add generic trusted keys framework
On Wed, 2020-10-07 at 15:37 +0530, Sumit Garg wrote:
> +/*
> + * trusted_destroy - clear and free the key's payload
> + */
> +static void trusted_destroy(struct key *key)
> +{
> + kfree_sensitive(key->payload.data[0]);
> +}
> +
> +struct key_type key_type_trusted = {
> + .name = "trusted",
> + .instantiate = trusted_instantiate,
> + .update = trusted_update,
> + .destroy = trusted_destroy,
> + .describe = user_describe,
> + .read = trusted_read,
> +};
> +EXPORT_SYMBOL_GPL(key_type_trusted);
> +
> +static int __init init_trusted(void)
> +{
> + int i, ret = 0;
> +
> + for (i = 0; i < ARRAY_SIZE(trusted_key_sources); i++) {
> + if (trusted_key_source &&
> + strncmp(trusted_key_source, trusted_key_sources[i].name,
> + strlen(trusted_key_sources[i].name)))
> + continue;
> +
> + trusted_key_ops = trusted_key_sources[i].ops;
> +
> + ret = trusted_key_ops->init();
> + if (!ret)
> + break;
> + }
In the case when the module paramater isn't specified and both TPM and
TEE are enabled, trusted_key_ops is set to the last source initialized.
After patch 2/4, the last trusted source initialized is TEE. If the
intention is to limit it to either TPM or TEE, then trusted_key_ops
should have a default value, which could be overwritten at runtime.
That would address Luke Hind's concerns of making the decision at
compile time.
trusted_key_ops should be defined as __ro_after_init, like is currently
done for other LSM structures.
> +
> + /*
> + * encrypted_keys.ko depends on successful load of this module even if
> + * trusted key implementation is not found.
> + */
> + if (ret == -ENODEV)
> + return 0;
> +
> + return ret;
> +}
> +
> +static void __exit cleanup_trusted(void)
> +{
> + trusted_key_ops->exit();
If the intention is really to support both TPM and TEE trusted keys at
the same time, as James suggested, then the same "for" loop as in
init_trusted() is needed here and probably elsewhere.
thanks,
Mimi
Re: [PATCH v7 1/4] powerpc: Refactor kexec functions to move arch independent code to kernel
On Tue, 2020-10-20 at 19:25 -0700, Lakshmi Ramasubramanian wrote: > On 10/20/20 1:00 PM, Mimi Zohar wrote: > > Hi Lakshmi, > > > > On Wed, 2020-09-30 at 13:59 -0700, Lakshmi Ramasubramanian wrote: > >> The functions remove_ima_buffer() and delete_fdt_mem_rsv() that handle > >> carrying forward the IMA measurement logs on kexec for powerpc do not > >> have architecture specific code, but they are currently defined for > >> powerpc only. > >> > >> remove_ima_buffer() and delete_fdt_mem_rsv() are used to remove > >> the IMA log entry from the device tree and free the memory reserved > >> for the log. These functions need to be defined even if the current > >> kernel does not support carrying forward IMA log across kexec since > >> the previous kernel could have supported that and therefore the current > >> kernel needs to free the allocation. > >> > >> Rename remove_ima_buffer() to remove_ima_kexec_buffer(). > >> Define remove_ima_kexec_buffer() and delete_fdt_mem_rsv() in kernel. > >> A later patch in this series will use these functions to free > >> the allocation, if any, made by the previous kernel for ARM64. > >> > >> Define FDT_PROP_IMA_KEXEC_BUFFER for the chosen node, namely > >> "linux,ima-kexec-buffer", that is added to the DTB to hold > >> the address and the size of the memory reserved to carry > >> the IMA measurement log. > > > >> Co-developed-by: Prakhar Srivastava > >> Signed-off-by: Prakhar Srivastava > >> Signed-off-by: Lakshmi Ramasubramanian > >> Reported-by: kernel test robot error: implicit > >> declaration of function 'delete_fdt_mem_rsv' > >> [-Werror,-Wimplicit-function-declaration] > > > > Much better! This version limits unnecessarily changing the existing > > code to adding a couple of debugging statements, but that looks to be > > about it. > Yes Mimi - that's correct. > > > > > Based on Chester Lin's "ima_arch" support for arm64 discussion, the IMA > > generic > > EFI support will be defined in ima/ima-efi.c. Similarly, I think it would > > make sense to put the generic device tree support in ima/ima_kexec_fdt.c or > > ima/ima_fdt.c, as opposed to kernel/. (Refer to my comments on 2/4 about > > the new file named ima_kexec_fdt.c.) > > The functions remove_ima_kexec_buffer() and delete_fdt_mem_rsv(), which > are defined in kernel/ima_kexec.c and kernel/kexec_file_fdt.c > respectively, are needed even when CONFIG_IMA is not defined. These > functions need to be called by the current kernel to free the ima kexec > buffer resources allocated by the previous kernel. This is the reason, > these functions are defined under "kernel" instead of > "security/integrity/ima". > > If there is a better location to move the above C files, please let me > know. I'll move them. Freeing the previous kernel measurement list is currently called from ima_load_kexec_buffer(), only after the measurement list has been restored. The only other time the memory is freed is when the allocated memory size isn't sufficient to hold the measurement list, which could happen if there is a delay between loading and executing the kexec. thanks, Mimi
Re: [PATCH] scsi: ufs: make sure scan sequence for multiple hosts
On 10/20/20 12:05 AM, Chanho Park wrote: > By doing scan as asynchronous way, scsi device scannning can be out of > order execution. It is no problem if there is a ufs host but the scsi > device name of each host can be changed according to the scan sequences. > > Ideal Case) host0 scan first > host0 will be started from /dev/sda > -> /dev/sdb (BootLUN0 of host0) > -> /dev/sdc (BootLUN1 of host1) > host1 will be started from /dev/sdd > > This might be an ideal case and we can easily find the host device by > this mappinng. > > However, Abnormal Case) host1 scan first, > host1 will be started from /dev/sda and host0 will be followed later. > > To make sure the scan sequences according to the host, we can use a > bitmap which hosts are scanned and wait until previous hosts are > finished to scan. This sounds completely wrong to me. No code should depend on the order in which LUNs are scanned. Please use the soft links created by udev instead of serializing LUN scanning. Thanks, Bart.
[PATCH] FROMLIST: input: add 2 kind of switch
>From ec9859ee01b7bc0e04255971e0fe97348847dab7 Mon Sep 17 00:00:00 2001
From: "hj2.im"
Date: Tue, 20 Oct 2020 16:57:04 +0900
Subject: [PATCH] FROMLIST: input: add 2 kind of switch
We need support to various accessories on the device,
some switch does not exist in switch list.
So added switch for the following purpose.
SW_COVER_ATTACHED is for the checking the cover
attached or not on the device. SW_EXT_PEN_ATTACHED is for the
checking the external pen attached or not on the device
Signed-off-by: hj2.im
---
include/linux/mod_devicetable.h| 2 +-
include/uapi/linux/input-event-codes.h | 4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 5b08a473cdba..897f5a3e7721 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -320,7 +320,7 @@ struct pcmcia_device_id {
#define INPUT_DEVICE_ID_LED_MAX0x0f
#define INPUT_DEVICE_ID_SND_MAX0x07
#define INPUT_DEVICE_ID_FF_MAX 0x7f
-#define INPUT_DEVICE_ID_SW_MAX 0x10
+#define INPUT_DEVICE_ID_SW_MAX 0x12
#define INPUT_DEVICE_ID_PROP_MAX 0x1f
#define INPUT_DEVICE_ID_MATCH_BUS 1
diff --git a/include/uapi/linux/input-event-codes.h
b/include/uapi/linux/input-event-codes.h
index 0c2e27d28e0a..8ca2acee1f92 100644
--- a/include/uapi/linux/input-event-codes.h
+++ b/include/uapi/linux/input-event-codes.h
@@ -889,7 +889,9 @@
#define SW_MUTE_DEVICE 0x0e /* set = device disabled */
#define SW_PEN_INSERTED0x0f /* set = pen inserted */
#define SW_MACHINE_COVER 0x10 /* set = cover closed */
-#define SW_MAX 0x10
+#define SW_COVER_ATTACHED 0x11 /* set = cover attached */
+#define SW_EXT_PEN_ATTACHED0x12 /* set = external pen attached */
+#define SW_MAX 0x12
#define SW_CNT (SW_MAX+1)
/*
--
2.11.0
[PATCH] FROMLIST: input: add 2 kind of switch
From ec9859ee01b7bc0e04255971e0fe97348847dab7 Mon Sep 17 00:00:00 2001
From: "hj2.im"
Date: Tue, 20 Oct 2020 16:57:04 +0900
Subject: [PATCH] FROMLIST: input: add 2 kind of switch
We need support to various accessories on the device,
some switch does not exist in switch list.
So added switch for the following purpose.
SW_COVER_ATTACHED is for the checking the cover
attached or not on the device. SW_EXT_PEN_ATTACHED is for the
checking the external pen attached or not on the device
Signed-off-by: hj2.im
---
include/linux/mod_devicetable.h| 2 +-
include/uapi/linux/input-event-codes.h | 4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 5b08a473cdba..897f5a3e7721 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -320,7 +320,7 @@ struct pcmcia_device_id {
#define INPUT_DEVICE_ID_LED_MAX0x0f
#define INPUT_DEVICE_ID_SND_MAX0x07
#define INPUT_DEVICE_ID_FF_MAX0x7f
-#define INPUT_DEVICE_ID_SW_MAX0x10
+#define INPUT_DEVICE_ID_SW_MAX0x12
#define INPUT_DEVICE_ID_PROP_MAX0x1f
#define INPUT_DEVICE_ID_MATCH_BUS1
diff --git a/include/uapi/linux/input-event-codes.h
b/include/uapi/linux/input-event-codes.h
index 0c2e27d28e0a..8ca2acee1f92 100644
--- a/include/uapi/linux/input-event-codes.h
+++ b/include/uapi/linux/input-event-codes.h
@@ -889,7 +889,9 @@
#define SW_MUTE_DEVICE0x0e /* set = device disabled */
#define SW_PEN_INSERTED0x0f /* set = pen inserted */
#define SW_MACHINE_COVER0x10 /* set = cover closed */
-#define SW_MAX0x10
+#define SW_COVER_ATTACHED0x11 /* set = cover attached */
+#define SW_EXT_PEN_ATTACHED0x12 /* set = external pen attached */
+#define SW_MAX0x12
#define SW_CNT(SW_MAX+1)
/*
--
2.11.0
[PATCH v2] Bluetooth: btusb: Add support for LG LGSBWAC92/TWCM-K505D
The LG LGSBWAC92/TWCM-K505D/EAT64454801/EAT64454802 (it goes by many
names) is a combo WiFi/Bluetooth module that's used in several models of
LG TVs. It uses the MediaTek MT7668AUN, which is already supported in
btusb, but this device has a non-MediaTek USB VID so to get it to work
we just need to add it to the list of devices to probe.
Device from /sys/kernel/debug/usb/devices:
T: Bus=09 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 6 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=043e ProdID=3109 Rev= 1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
S: SerialNumber=0
C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms
I:* If#= 2 Alt= 0 #EPs= 8 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=08(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=09(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Signed-off-by: Forest Crossman
---
Changes from v1:
- Added /sys/kernel/debug/usb/devices info.
- Specify device with USB_DEVICE_AND_INTERFACE_INFO instead of just
USB_DEVICE.
---
drivers/bluetooth/btusb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 5f022e9cf667..fbc7b87f0190 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -366,6 +366,8 @@ static const struct usb_device_id blacklist_table[] = {
/* MediaTek Bluetooth devices */
{ USB_VENDOR_AND_INTERFACE_INFO(0x0e8d, 0xe0, 0x01, 0x01),
.driver_info = BTUSB_MEDIATEK },
+ { USB_DEVICE_AND_INTERFACE_INFO(0x043e, 0x3109, 0xe0, 0x01, 0x01),
+ .driver_info = BTUSB_MEDIATEK },
/* Additional Realtek 8723AE Bluetooth devices */
{ USB_DEVICE(0x0930, 0x021d), .driver_info = BTUSB_REALTEK },
--
2.20.1
[PATCH] thermal: replace spin_lock_irqsave by spin_lock in hard IRQ
The code has been in a irq-disabled context since it is hard IRQ. There
is no necessity to do it again.
Signed-off-by: Tian Tao
---
drivers/thermal/rcar_thermal.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
index 5c2a13b..6ae757d 100644
--- a/drivers/thermal/rcar_thermal.c
+++ b/drivers/thermal/rcar_thermal.c
@@ -409,16 +409,15 @@ static irqreturn_t rcar_thermal_irq(int irq, void *data)
{
struct rcar_thermal_common *common = data;
struct rcar_thermal_priv *priv;
- unsigned long flags;
u32 status, mask;
- spin_lock_irqsave(&common->lock, flags);
+ spin_lock(&common->lock);
mask= rcar_thermal_common_read(common, INTMSK);
status = rcar_thermal_common_read(common, STR);
rcar_thermal_common_write(common, STR, 0x000F0F0F & mask);
- spin_unlock_irqrestore(&common->lock, flags);
+ spin_unlock(&common->lock);
status = status & ~mask;
--
2.7.4
arch/mips/bmips/dma.c:43:12: warning: no previous prototype for 'phys_to_dma'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: c4d6fe7311762f2e03b3c27ad38df7c40c80cc93
commit: 5ceda74093a5c1c3f42a02b894df031f3bbc9af1 dma-direct: rename and cleanup
__phys_to_dma
date: 6 weeks ago
config: mips-randconfig-r022-20201021 (attached as .config)
compiler: mips-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5ceda74093a5c1c3f42a02b894df031f3bbc9af1
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 5ceda74093a5c1c3f42a02b894df031f3bbc9af1
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> arch/mips/bmips/dma.c:43:12: warning: no previous prototype for
>> 'phys_to_dma' [-Wmissing-prototypes]
43 | dma_addr_t phys_to_dma(struct device *dev, phys_addr_t pa)
|^~~
arch/mips/bmips/dma.c:55:13: warning: no previous prototype for
'dma_to_phys' [-Wmissing-prototypes]
55 | phys_addr_t dma_to_phys(struct device *dev, dma_addr_t dma_addr)
| ^~~
arch/mips/bmips/dma.c:67:6: warning: no previous prototype for
'arch_sync_dma_for_cpu_all' [-Wmissing-prototypes]
67 | void arch_sync_dma_for_cpu_all(void)
| ^
vim +/phys_to_dma +43 arch/mips/bmips/dma.c
42
> 43 dma_addr_t phys_to_dma(struct device *dev, phys_addr_t pa)
44 {
45 struct bmips_dma_range *r;
46
47 for (r = bmips_dma_ranges; r && r->size; r++) {
48 if (pa >= r->child_addr &&
49 pa < (r->child_addr + r->size))
50 return pa - r->child_addr + r->parent_addr;
51 }
52 return pa;
53 }
54
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH] FROMLIST: input: add 2 kind of switch
>From ec9859ee01b7bc0e04255971e0fe97348847dab7 Mon Sep 17 00:00:00 2001
From: "hj2.im"
Date: Tue, 20 Oct 2020 16:57:04 +0900
Subject: [PATCH] FROMLIST: input: add 2 kind of switch
We need support to various accessories on the device,
some switch does not exist in switch list.
So added switch for the following purpose.
SW_COVER_ATTACHED is for the checking the cover
attached or not on the device. SW_EXT_PEN_ATTACHED is for the
checking the external pen attached or not on the device
Signed-off-by: hj2.im
---
include/linux/mod_devicetable.h| 2 +-
include/uapi/linux/input-event-codes.h | 4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 5b08a473cdba..897f5a3e7721 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -320,7 +320,7 @@ struct pcmcia_device_id {
#define INPUT_DEVICE_ID_LED_MAX0x0f
#define INPUT_DEVICE_ID_SND_MAX0x07
#define INPUT_DEVICE_ID_FF_MAX 0x7f
-#define INPUT_DEVICE_ID_SW_MAX 0x10
+#define INPUT_DEVICE_ID_SW_MAX 0x12
#define INPUT_DEVICE_ID_PROP_MAX 0x1f
#define INPUT_DEVICE_ID_MATCH_BUS 1
diff --git a/include/uapi/linux/input-event-codes.h
b/include/uapi/linux/input-event-codes.h
index 0c2e27d28e0a..8ca2acee1f92 100644
--- a/include/uapi/linux/input-event-codes.h
+++ b/include/uapi/linux/input-event-codes.h
@@ -889,7 +889,9 @@
#define SW_MUTE_DEVICE 0x0e /* set = device disabled */
#define SW_PEN_INSERTED0x0f /* set = pen inserted */
#define SW_MACHINE_COVER 0x10 /* set = cover closed */
-#define SW_MAX 0x10
+#define SW_COVER_ATTACHED 0x11 /* set = cover attached */
+#define SW_EXT_PEN_ATTACHED0x12 /* set = external pen attached */
+#define SW_MAX 0x12
#define SW_CNT (SW_MAX+1)
/*
--
2.11.0
Re: [PATCH v3 01/16] dt-bindings: usb: usb-hcd: Convert generic USB properties to DT schema
On Tue, 2020-10-20 at 14:20 +0300, Serge Semin wrote:
> The generic USB HCD properties have been described in the legacy bindings
> text file: Documentation/devicetree/bindings/usb/generic.txt . Let's
> convert it' content into the USB HCD DT schema properties so all USB DT
^ its?
> nodes would be validated to have them properly utilized.
>
> Signed-off-by: Serge Semin
> Reviewed-by: Rob Herring
>
> ---
>
> Changelog v2:
> - Discard '|' in all the new properties, since we don't need to preserve
> the text formatting.
> - Convert abbreviated form of the "maximum-speed" enum restriction into
> the multi-lined version of the list.
> - Drop quotes from around the string constants.
> ---
> .../devicetree/bindings/usb/generic.txt | 57
> .../devicetree/bindings/usb/usb-hcd.yaml | 88 +++
Do we need change the file name or modify it's title?
the title is "Generic USB Host Controller Device Tree Bindings", but
some generic properties, such as, dr_mode, usb-role-switch, otg related
ones, are usually used by DRD controller, this may cause some confusion.
> 2 files changed, 88 insertions(+), 57 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/usb/generic.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/generic.txt
> b/Documentation/devicetree/bindings/usb/generic.txt
> deleted file mode 100644
> index ba472e7aefc9..
> --- a/Documentation/devicetree/bindings/usb/generic.txt
> +++ /dev/null
> @@ -1,57 +0,0 @@
> -Generic USB Properties
> -
> -Optional properties:
> - - maximum-speed: tells USB controllers we want to work up to a certain
> - speed. Valid arguments are "super-speed-plus",
> - "super-speed", "high-speed", "full-speed" and
> - "low-speed". In case this isn't passed via DT, USB
> - controllers should default to their maximum HW
> - capability.
> - - dr_mode: tells Dual-Role USB controllers that we want to work on a
> - particular mode. Valid arguments are "host",
> - "peripheral" and "otg". In case this attribute isn't
> - passed via DT, USB DRD controllers should default to
> - OTG.
> - - phy_type: tells USB controllers that we want to configure the core to
> support
> - a UTMI+ PHY with an 8- or 16-bit interface if UTMI+ is
> - selected. Valid arguments are "utmi" and "utmi_wide".
> - In case this isn't passed via DT, USB controllers should
> - default to HW capability.
> - - otg-rev: tells usb driver the release number of the OTG and EH supplement
> - with which the device and its descriptors are compliant,
> - in binary-coded decimal (i.e. 2.0 is 0200H). This
> - property is used if any real OTG features(HNP/SRP/ADP)
> - is enabled, if ADP is required, otg-rev should be
> - 0x0200 or above.
> - - companion: phandle of a companion
> - - hnp-disable: tells OTG controllers we want to disable OTG HNP, normally
> HNP
> - is the basic function of real OTG except you want it
> - to be a srp-capable only B device.
> - - srp-disable: tells OTG controllers we want to disable OTG SRP, SRP is
> - optional for OTG device.
> - - adp-disable: tells OTG controllers we want to disable OTG ADP, ADP is
> - optional for OTG device.
> - - usb-role-switch: boolean, indicates that the device is capable of
> assigning
> - the USB data role (USB host or USB device) for a given
> - USB connector, such as Type-C, Type-B(micro).
> - see connector/usb-connector.yaml.
> - - role-switch-default-mode: indicating if usb-role-switch is enabled, the
> - device default operation mode of controller while usb
> - role is USB_ROLE_NONE. Valid arguments are "host" and
> - "peripheral". Defaults to "peripheral" if not
> - specified.
> -
> -
> -This is an attribute to a USB controller such as:
> -
> -dwc3@4a03 {
> - compatible = "synopsys,dwc3";
> - reg = <0x4a03 0xcfff>;
> - interrupts = <0 92 4>
> - usb-phy = <&usb2_phy>, <&usb3,phy>;
> - maximum-speed = "super-speed";
> - dr_mode = "otg";
> - phy_type = "utmi_wide";
> - otg-rev = <0x0200>;
> - adp-disable;
> -};
> diff --git a/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> b/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> index 7263b7f2b510..ee7ea205c71d 100644
> --- a/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> +++ b/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> @@ -22,9 +22,97 @@ properties:
> description:
>Name specifier for the US
[PATCH v2 2/6] spi: cadence-quadspi: Disable the DAC for Intel LGM SoC
From: Ramuthevar Vadivel Murugan
On Intel Lightning Mountain(LGM) SoCs QSPI controller do not use
Direct Access Controller(DAC).
This patch adds a quirk to disable the Direct Access Controller
for data transfer instead it uses indirect data transfer.
Signed-off-by: Ramuthevar Vadivel Murugan
---
drivers/spi/spi-cadence-quadspi.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/spi/spi-cadence-quadspi.c
b/drivers/spi/spi-cadence-quadspi.c
index d7b10c46fa70..3d017b484114 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -1106,6 +1106,13 @@ static void cqspi_controller_init(struct cqspi_st *cqspi)
reg |= CQSPI_REG_CONFIG_ENB_DIR_ACC_CTRL;
writel(reg, cqspi->iobase + CQSPI_REG_CONFIG);
+ /* Disable direct access controller */
+ if (!cqspi->use_direct_mode) {
+ reg = readl(cqspi->iobase + CQSPI_REG_CONFIG);
+ reg &= ~CQSPI_REG_CONFIG_ENB_DIR_ACC_CTRL;
+ writel(reg, cqspi->iobase + CQSPI_REG_CONFIG);
+ }
+
cqspi_controller_enable(cqspi, 1);
}
@@ -1388,6 +1395,10 @@ static const struct cqspi_driver_platdata am654_ospi = {
.quirks = CQSPI_NEEDS_WR_DELAY,
};
+static const struct cqspi_driver_platdata intel_lgm_qspi = {
+ .quirks = CQSPI_DISABLE_DAC_MODE,
+};
+
static const struct of_device_id cqspi_dt_ids[] = {
{
.compatible = "cdns,qspi-nor",
@@ -1403,6 +1414,7 @@ static const struct of_device_id cqspi_dt_ids[] = {
},
{
.compatible = "intel,lgm-qspi",
+ .data = &intel_lgm_qspi,
},
{ /* end of table */ }
};
--
2.11.0
[PATCH v2 6/6] dt-bindings: spi: Add compatible for Intel LGM SoC
From: Ramuthevar Vadivel Murugan Add compatible string for Intel LGM SoC. Signed-off-by: Ramuthevar Vadivel Murugan --- Documentation/devicetree/bindings/spi/cadence-quadspi.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml b/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml index 57be1a730e7b..44378d2d2b9e 100644 --- a/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml +++ b/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml @@ -19,6 +19,7 @@ properties: - const: cdns,qspi-nor - const: ti,k2g-qspi, cdns,qspi-nor - const: ti,am654-ospi, cdns,qspi-nor + - const: intel,lgm-qspi, cdns,qspi-nor reg: items: -- 2.11.0
[PATCH v2 4/6] spi: Move cadence-quadspi.txt to Documentation/devicetree/bindings/spi
From: Ramuthevar Vadivel Murugan
Move the Documentation/devicetree/bindings/mtd/cadence-quadspi.txt to
Documentation/devicetree/bindings/spi/
Signed-off-by: Ramuthevar Vadivel Murugan
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/{mtd => spi}/cadence-quadspi.txt | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/{mtd => spi}/cadence-quadspi.txt
(100%)
diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
b/Documentation/devicetree/bindings/spi/cadence-quadspi.txt
similarity index 100%
rename from Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
rename to Documentation/devicetree/bindings/spi/cadence-quadspi.txt
--
2.11.0
[PATCH v2 3/6] spi: cadence-quadspi: Add multi-chipselect support for Intel LGM SoC
From: Ramuthevar Vadivel Murugan
Add multiple chipselect support for Intel LGM SoCs,
currently QSPI-NOR and QSPI-NAND supported.
Signed-off-by: Ramuthevar Vadivel Murugan
---
drivers/spi/spi-cadence-quadspi.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/spi/spi-cadence-quadspi.c
b/drivers/spi/spi-cadence-quadspi.c
index 3d017b484114..3bf6d3697631 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -38,6 +38,7 @@
/* Capabilities */
#define CQSPI_SUPPORTS_OCTAL BIT(0)
+#define CQSPI_SUPPORTS_MULTI_CHIPSELECT BIT(1)
struct cqspi_st;
@@ -75,6 +76,7 @@ struct cqspi_st {
boolis_decoded_cs;
u32 fifo_depth;
u32 fifo_width;
+ u32 num_chipselect;
boolrclk_en;
u32 trigger_address;
u32 wr_delay;
@@ -1070,6 +1072,14 @@ static int cqspi_of_get_pdata(struct cqspi_st *cqspi)
return -ENXIO;
}
+ if (!cqspi->use_direct_mode) {
+ if (of_property_read_u32(np, "num-chipselect",
+&cqspi->num_chipselect)) {
+ dev_err(dev, "couldn't determine number of cs\n");
+ return -ENXIO;
+ }
+ }
+
cqspi->rclk_en = of_property_read_bool(np, "cdns,rclk-en");
return 0;
@@ -1307,6 +1317,9 @@ static int cqspi_probe(struct platform_device *pdev)
cqspi->current_cs = -1;
cqspi->sclk = 0;
+ if (ddata->hwcaps_mask & CQSPI_SUPPORTS_MULTI_CHIPSELECT)
+ master->num_chipselect = cqspi->num_chipselect;
+
ret = cqspi_setup_flash(cqspi);
if (ret) {
dev_err(dev, "failed to setup flash parameters %d\n", ret);
@@ -1396,6 +1409,7 @@ static const struct cqspi_driver_platdata am654_ospi = {
};
static const struct cqspi_driver_platdata intel_lgm_qspi = {
+ .hwcaps_mask = CQSPI_SUPPORTS_MULTI_CHIPSELECT,
.quirks = CQSPI_DISABLE_DAC_MODE,
};
--
2.11.0
[PATCH v2 5/6] dt-bindings: spi: Convert cadence-quadspi.txt to cadence-quadspi.yaml
From: Ramuthevar Vadivel Murugan
Convert the cadence-quadspi.txt documentation to cadence-quadspi.yaml
remove the cadence-quadspi.txt from Documentation/devicetree/bindings/spi/
Signed-off-by: Ramuthevar Vadivel Murugan
---
.../devicetree/bindings/spi/cadence-quadspi.txt| 67 --
.../devicetree/bindings/spi/cadence-quadspi.yaml | 148 +
2 files changed, 148 insertions(+), 67 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/spi/cadence-quadspi.txt
create mode 100644 Documentation/devicetree/bindings/spi/cadence-quadspi.yaml
diff --git a/Documentation/devicetree/bindings/spi/cadence-quadspi.txt
b/Documentation/devicetree/bindings/spi/cadence-quadspi.txt
deleted file mode 100644
index 945be7d5b236..
--- a/Documentation/devicetree/bindings/spi/cadence-quadspi.txt
+++ /dev/null
@@ -1,67 +0,0 @@
-* Cadence Quad SPI controller
-
-Required properties:
-- compatible : should be one of the following:
- Generic default - "cdns,qspi-nor".
- For TI 66AK2G SoC - "ti,k2g-qspi", "cdns,qspi-nor".
- For TI AM654 SoC - "ti,am654-ospi", "cdns,qspi-nor".
-- reg : Contains two entries, each of which is a tuple consisting of a
- physical address and length. The first entry is the address and
- length of the controller register set. The second entry is the
- address and length of the QSPI Controller data area.
-- interrupts : Unit interrupt specifier for the controller interrupt.
-- clocks : phandle to the Quad SPI clock.
-- cdns,fifo-depth : Size of the data FIFO in words.
-- cdns,fifo-width : Bus width of the data FIFO in bytes.
-- cdns,trigger-address : 32-bit indirect AHB trigger address.
-
-Optional properties:
-- cdns,is-decoded-cs : Flag to indicate whether decoder is used or not.
-- cdns,rclk-en : Flag to indicate that QSPI return clock is used to latch
- the read data rather than the QSPI clock. Make sure that QSPI return
- clock is populated on the board before using this property.
-
-Optional subnodes:
-Subnodes of the Cadence Quad SPI controller are spi slave nodes with additional
-custom properties:
-- cdns,read-delay : Delay for read capture logic, in clock cycles
-- cdns,tshsl-ns : Delay in nanoseconds for the length that the master
- mode chip select outputs are de-asserted between
- transactions.
-- cdns,tsd2d-ns : Delay in nanoseconds between one chip select being
- de-activated and the activation of another.
-- cdns,tchsh-ns : Delay in nanoseconds between last bit of current
- transaction and deasserting the device chip select
- (qspi_n_ss_out).
-- cdns,tslch-ns : Delay in nanoseconds between setting qspi_n_ss_out low
- and first bit transfer.
-- resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : Must include either "qspi" and/or "qspi-ocp".
-
-Example:
-
- qspi: spi@ff705000 {
- compatible = "cdns,qspi-nor";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0xff705000 0x1000>,
- <0xffa0 0x1000>;
- interrupts = <0 151 4>;
- clocks = <&qspi_clk>;
- cdns,is-decoded-cs;
- cdns,fifo-depth = <128>;
- cdns,fifo-width = <4>;
- cdns,trigger-address = <0x>;
- resets = <&rst QSPI_RESET>, <&rst QSPI_OCP_RESET>;
- reset-names = "qspi", "qspi-ocp";
-
- flash0: n25q00@0 {
- ...
- cdns,read-delay = <4>;
- cdns,tshsl-ns = <50>;
- cdns,tsd2d-ns = <50>;
- cdns,tchsh-ns = <4>;
- cdns,tslch-ns = <4>;
- };
- };
diff --git a/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml
b/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml
new file mode 100644
index ..57be1a730e7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml
@@ -0,0 +1,148 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/cadence-quadspi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cadence Quad SPI controller
+
+maintainers:
+ - Vadivel Murugan
+
+allOf:
+ - $ref: "spi-controller.yaml#"
+
+properties:
+ compatible:
+oneOf:
+ - items:
+ - const: cdns,qspi-nor
+ - const: ti,k2g-qspi, cdns,qspi-nor
+ - const: ti,am654-ospi, cdns,qspi-nor
+
+ reg:
+items:
+ - description: the controller register set
+ - description: the controller data area
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ cdns,fifo-depth:
+description:
+ Size of the data FIFO in words.
+$ref: "/schemas/types.yaml#/defi
[PATCH v2 0/6] spi: cadence-quadspi: Add QSPI controller support for Intel LGM SoC
Add QSPI controller support for Intel LGM SoC. Note from Vignesh(mtd subsystem maintainer): This series is a subset of "[PATCH v12 0/4] spi: cadence-quadspi: Add support for the Cadence QSPI controller" by Ramuthevar,Vadivel MuruganX that intended to move cadence-quadspi driver to spi-mem framework Those patches were trying to accomplish too many things in a single set of patches and need to split into smaller patches. This is reduced version of above series. Changes that are intended to make migration easy are split into separate patches. Patches 1 to 3 drop features that cannot be supported under spi-mem at the moment (backward compatibility is maintained). Patch 4-5 are trivial cleanups. Patch 6 does the actual conversion to spi-mem and patch 7 moves the driver to drivers/spi folder. I have tested both INDAC mode (used by non TI platforms like Altera SoCFPGA) and DAC mode (used by TI platforms) on TI EVMs. Patches to move move bindings over to "Documentation/devicetree/bindings/spi/" directory and also conversion of bindig doc to YAML will be posted separately. Support for Intel platform would follow that. Reference: https://lkml.org/lkml/2020/6/1/50 --- v2: - Rob's review comments update for dt-bindings - add 'oneOf' for compatible selection - drop un-neccessary descriptions - add the cdns,is-decoded-cs and cdns,rclk-en properties as schema - remove 'allOf' in not required place - add AdditionalProperties false - add minItems/maxItems for qspi reset attributes resend-v1: - As per Mark's suggestion , reorder the patch series 1-3 driver support patches, series 4-6 dt-bindings patches. v1: - initial version Ramuthevar Vadivel Murugan (6): spi: cadence-quadspi: Add QSPI support for Intel LGM SoC spi: cadence-quadspi: Disable the DAC for Intel LGM SoC spi: cadence-quadspi: Add multi-chipselect support for Intel LGM SoC spi: Move cadence-quadspi.txt to Documentation/devicetree/bindings/spi dt-bindings: spi: Convert cadence-quadspi.txt to cadence-quadspi.yaml dt-bindings: spi: Add compatible for Intel LGM SoC .../devicetree/bindings/mtd/cadence-quadspi.txt| 67 - .../devicetree/bindings/spi/cadence-quadspi.yaml | 149 + drivers/spi/Kconfig| 2 +- drivers/spi/spi-cadence-quadspi.c | 29 4 files changed, 179 insertions(+), 68 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mtd/cadence-quadspi.txt create mode 100644 Documentation/devicetree/bindings/spi/cadence-quadspi.yaml -- 2.11.0
[PATCH v2 1/6] spi: cadence-quadspi: Add QSPI support for Intel LGM SoC
From: Ramuthevar Vadivel Murugan
Add QSPI controller support for Intel LGM SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
---
drivers/spi/Kconfig | 2 +-
drivers/spi/spi-cadence-quadspi.c | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index d2c976e55b8b..926da61eee5a 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -203,7 +203,7 @@ config SPI_CADENCE
config SPI_CADENCE_QUADSPI
tristate "Cadence Quad SPI controller"
- depends on OF && (ARM || ARM64 || COMPILE_TEST)
+ depends on OF && (ARM || ARM64 || X86 || COMPILE_TEST)
help
Enable support for the Cadence Quad SPI Flash controller.
diff --git a/drivers/spi/spi-cadence-quadspi.c
b/drivers/spi/spi-cadence-quadspi.c
index 40938cf3806d..d7b10c46fa70 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -1401,6 +1401,9 @@ static const struct of_device_id cqspi_dt_ids[] = {
.compatible = "ti,am654-ospi",
.data = &am654_ospi,
},
+ {
+ .compatible = "intel,lgm-qspi",
+ },
{ /* end of table */ }
};
--
2.11.0
Re: [External] Re: [PATCH] mm/memory.c: Introduce non-atomic __{Set,Clear}PageSwapCache
On 10/20/20 9:08 PM, Muchun Song wrote:
On Tue, Oct 20, 2020 at 7:51 PM Xu, Yanfei wrote:
On 10/19/20 10:58 PM, Muchun Song wrote:
On Mon, Oct 19, 2020 at 8:31 PM Michal Hocko wrote:
On Mon 19-10-20 18:15:20, Muchun Song wrote:
For the exclusive reference page, the non-atomic operations is enough,
so replace them to non-atomic operations.
I do expect you do not see any difference in runtime and this is mostly
driven by the code reading, right? Being explicit about this in the code
would be preferred.
Yeah, just code reading.And the set_bit and __set_bit is actually different
on some architectures. Thanks.
No objection to the change.
Signed-off-by: Muchun Song
With an improved changelog
Acked-by: Michal Hocko
---
include/linux/page-flags.h | 2 ++
mm/memory.c| 4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index fbbb841a9346..ec039dde5e4b 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -401,6 +401,8 @@ static __always_inline int PageSwapCache(struct page *page)
}
SETPAGEFLAG(SwapCache, swapcache, PF_NO_TAIL)
CLEARPAGEFLAG(SwapCache, swapcache, PF_NO_TAIL)
+__SETPAGEFLAG(SwapCache, swapcache, PF_NO_TAIL)
+__CLEARPAGEFLAG(SwapCache, swapcache, PF_NO_TAIL)
#else
PAGEFLAG_FALSE(SwapCache)
#endif
diff --git a/mm/memory.c b/mm/memory.c
index 2d267ef6621a..02dd62da26e0 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3128,10 +3128,10 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
set_page_private(page, entry.val);
/* Tell memcg to use swap ownership records */
- SetPageSwapCache(page);
+ __SetPageSwapCache(page);
Good evening, Muchun. I found there are still some places could be
replaced with __SetPageSwapCache（）. Such as shmem_replace_page（）, why
Yeah, thanks for your suggestion.
PG_locked has been set before SetPageSwapCache（） is involved.
In this case, It doesn't matter whether PG_locked is set before
SetPageSwapCache.
Sorry for this mistake. PG_locked is used for disk I/O.
Would you please to check the rest places? :)
Ok, I'll take a look. Thanks.
Thanks
Acked-by: Yanfei Xu
err = mem_cgroup_charge(page, vma->vm_mm,
GFP_KERNEL);
- ClearPageSwapCache(page);
+ __ClearPageSwapCache(page);
if (err) {
ret = VM_FAULT_OOM;
goto out_page;
--
2.20.1
--
Michal Hocko
SUSE Labs
--
Yours,
Muchun
Re: [PATCH 10/11] [DEBUG] firmware: arm_scmi: add custom_dummy SCMI devname
On 10/14/20 11:05 AM, Cristian Marussi wrote:
Add custom_dummy SCMI devname.
Signed-off-by: Cristian Marussi
---
drivers/firmware/arm_scmi/driver.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/firmware/arm_scmi/driver.c
b/drivers/firmware/arm_scmi/driver.c
index 55df134c2338..5c39a738866a 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -993,6 +993,7 @@ static struct scmi_prot_devnames devnames[] = {
{ SCMI_PROTOCOL_CLOCK, { "clocks" },},
{ SCMI_PROTOCOL_SENSOR, { "hwmon" },},
{ SCMI_PROTOCOL_RESET, { "reset" },},
+ { SCMI_PROTOCOL_CUSTOM_DUMMY, { "custom_dummy" },},
Hi Cristian,
Thanks for the sample dummy custom protocol and driver!
The problem with adding scmi devname into the array is that every time a
custom vendor protocol is added, the array has to be extended. Instead
since the scmi spec supports the range 0x80-0xff for custom protocols,
why not check for that range in scmi_create_protocol_devices and go
ahead with registering the creating the protocol device via
scmi_create_protocol_device?
};
static inline void
--
Warm Regards
Thara
Re: [PATCH 06/11] firmware: arm_scmi: add support for protocol modularization
On 10/14/20 11:05 AM, Cristian Marussi wrote: Modify protocol initialization callback adding a new parameter representing a reference to the available xfer core operations and introduce a macro to simply register with the core new protocols as loadable drivers. Keep standard protocols as builtin. Signed-off-by: Cristian Marussi --- drivers/firmware/arm_scmi/base.c| 56 ++ drivers/firmware/arm_scmi/bus.c | 14 - drivers/firmware/arm_scmi/clock.c | 56 +- drivers/firmware/arm_scmi/common.h | 42 +- drivers/firmware/arm_scmi/driver.c | 50 ++-- drivers/firmware/arm_scmi/perf.c| 88 +++-- drivers/firmware/arm_scmi/power.c | 46 --- drivers/firmware/arm_scmi/reset.c | 46 --- drivers/firmware/arm_scmi/sensors.c | 52 + drivers/firmware/arm_scmi/system.c | 16 -- include/linux/scmi_protocol.h | 18 +- 11 files changed, 288 insertions(+), 196 deletions(-) diff --git a/drivers/firmware/arm_scmi/base.c b/drivers/firmware/arm_scmi/base.c index f40821eeb103..8d7214fd2187 100644 --- a/drivers/firmware/arm_scmi/base.c +++ b/drivers/firmware/arm_scmi/base.c @@ -15,6 +15,8 @@ #define SCMI_BASE_NUM_SOURCES 1 #define SCMI_BASE_MAX_CMD_ERR_COUNT 1024 +static const struct scmi_xfer_ops *ops; Minor nit. I would consider renaming ops to something more meaningful like xfer_ops (or anything that makes sense). ops by itself leads to confusion with ops in scmo_protocol and in scmi_protocol_events. Same suggestion for all other declarations of ops in this patch. -- Warm Regards Thara
Re: [PATCH 01/11] firmware: arm_scmi: review protocol registration interface
Hi Cristian,
Thanks for this series!
On 10/14/20 11:05 AM, Cristian Marussi wrote:
Extend common protocol registration routines and provide some new generic
protocols' init/deinit helpers that tracks protocols' users and automatically
perform the proper initialization/de-initialization on demand.
Convert all protocols to use new registration schema while modifying only Base
protocol to use also the new initialization helpers.
All other standard protocols' initialization is still umodified and bound to
SCMI devices probing.
Signed-off-by: Cristian Marussi
---
drivers/firmware/arm_scmi/base.c| 10 +-
drivers/firmware/arm_scmi/bus.c | 61 +++---
drivers/firmware/arm_scmi/clock.c | 10 +-
drivers/firmware/arm_scmi/common.h | 31 -
drivers/firmware/arm_scmi/driver.c | 168 +++-
drivers/firmware/arm_scmi/notify.c | 3 +-
drivers/firmware/arm_scmi/perf.c| 10 +-
drivers/firmware/arm_scmi/power.c | 10 +-
drivers/firmware/arm_scmi/reset.c | 10 +-
drivers/firmware/arm_scmi/sensors.c | 10 +-
drivers/firmware/arm_scmi/system.c | 8 +-
include/linux/scmi_protocol.h | 6 +-
12 files changed, 298 insertions(+), 39 deletions(-)
diff --git a/drivers/firmware/arm_scmi/base.c b/drivers/firmware/arm_scmi/base.c
index 017e5d8bd869..f19e08ed4369 100644
--- a/drivers/firmware/arm_scmi/base.c
+++ b/drivers/firmware/arm_scmi/base.c
@@ -318,7 +318,7 @@ static const struct scmi_event_ops base_event_ops = {
.fill_custom_report = scmi_base_fill_custom_report,
};
-int scmi_base_protocol_init(struct scmi_handle *h)
+static int scmi_base_protocol_init(struct scmi_handle *h)
{
int id, ret;
u8 *prot_imp;
@@ -365,3 +365,11 @@ int scmi_base_protocol_init(struct scmi_handle *h)
return 0;
}
+
+static struct scmi_protocol scmi_base = {
+ .id = SCMI_PROTOCOL_BASE,
+ .init = &scmi_base_protocol_init,
+ .ops = NULL,
+};
+
+DEFINE_SCMI_PROTOCOL_REGISTER_UNREGISTER(base, scmi_base)
diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
index 1377ec76a45d..afa2e4818a2b 100644
--- a/drivers/firmware/arm_scmi/bus.c
+++ b/drivers/firmware/arm_scmi/bus.c
@@ -16,7 +16,7 @@
#include "common.h"
static DEFINE_IDA(scmi_bus_id);
-static DEFINE_IDR(scmi_protocols);
+static DEFINE_IDR(scmi_available_protocols);
static DEFINE_SPINLOCK(protocol_lock);
static const struct scmi_device_id *
@@ -51,13 +51,29 @@ static int scmi_dev_match(struct device *dev, struct
device_driver *drv)
return 0;
}
+const struct scmi_protocol *scmi_get_protocol(int protocol_id)
+{
+ const struct scmi_protocol *proto;
+
+ proto = idr_find(&scmi_available_protocols, protocol_id);
+ if (!proto) {
+ pr_warn("SCMI Protocol 0x%x not found!\n", protocol_id);
+ return NULL;
+ }
+
+ pr_debug("GOT SCMI Protocol 0x%x\n", protocol_id);
+
+ return proto;
+}
+
static int scmi_protocol_init(int protocol_id, struct scmi_handle *handle)
{
- scmi_prot_init_fn_t fn = idr_find(&scmi_protocols, protocol_id);
+ const struct scmi_protocol *proto;
- if (unlikely(!fn))
+ proto = idr_find(&scmi_available_protocols, protocol_id);
+ if (!proto)
return -EINVAL;
Any reason not to use the above scmi_get_protocol here ?
- return fn(handle);
+ return proto->init(handle);
}
static int scmi_protocol_dummy_init(struct scmi_handle *handle)
@@ -84,7 +100,7 @@ static int scmi_dev_probe(struct device *dev)
return ret;
/* Skip protocol initialisation for additional devices */
- idr_replace(&scmi_protocols, &scmi_protocol_dummy_init,
+ idr_replace(&scmi_available_protocols, &scmi_protocol_dummy_init,
scmi_dev->protocol_id);
return scmi_drv->probe(scmi_dev);
@@ -194,26 +210,45 @@ void scmi_set_handle(struct scmi_device *scmi_dev)
scmi_dev->handle = scmi_handle_get(&scmi_dev->dev);
}
-int scmi_protocol_register(int protocol_id, scmi_prot_init_fn_t fn)
+int scmi_protocol_register(struct scmi_protocol *proto)
{
int ret;
+ if (!proto) {
+ pr_err("invalid protocol\n");
+ return -EINVAL;
+ }
+
+ if (!proto->init) {
+ pr_err("missing .init() for protocol 0x%x\n", proto->id);
+ return -EINVAL;
+ }
+
spin_lock(&protocol_lock);
- ret = idr_alloc(&scmi_protocols, fn, protocol_id, protocol_id + 1,
- GFP_ATOMIC);
+ ret = idr_alloc(&scmi_available_protocols, proto,
+ proto->id, proto->id + 1, GFP_ATOMIC);
spin_unlock(&protocol_lock);
- if (ret != protocol_id)
- pr_err("unable to allocate SCMI idr slot, err %d\n", ret);
+ if (ret != proto->id) {
+ pr_err("unable to allocate SCMI idr slot for 0x%x - err %d\n",
+
Re: [PATCH 03/11] firmware: arm_scmi: introduce common protocol interface
On 10/14/20 11:05 AM, Cristian Marussi wrote:
Introduce generic get_ops/put_ops handle operations: any protocol, both
standard or custom, now exposes its operations through this common
interface which internally takes care to account for protocols' usage:
protocols' initialization is now performed on demand as soon as the first
user shows up while deinitialization (if any) is performed once
the last user of a protocol has gone.
Registered events' notifier are tracked too against the related protocol.
Convert all SCMI drivers to the new interface too.
Signed-off-by: Cristian Marussi
---
[...]
diff --git a/drivers/firmware/arm_scmi/driver.c
b/drivers/firmware/arm_scmi/driver.c
index bad1d0130e96..049220efd227 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -585,7 +585,7 @@ void *scmi_get_proto_priv(const struct scmi_handle *handle,
u8 protocol_id)
* Return: A reference to an initialized protocol instance or error on
failure.
*/
static struct scmi_protocol_instance * __must_check
-scmi_get_protocol_instance(struct scmi_handle *handle, u8 protocol_id)
+scmi_get_protocol_instance(const struct scmi_handle *handle, u8 protocol_id)
{
int ret = -ENOMEM;
void *gid;
@@ -655,7 +655,7 @@ scmi_get_protocol_instance(struct scmi_handle *handle, u8
protocol_id)
*
* Return: 0 if protocol was acquired successfully.
*/
-int scmi_acquire_protocol(struct scmi_handle *handle, u8 protocol_id)
+int scmi_acquire_protocol(const struct scmi_handle *handle, u8 protocol_id)
{
return IS_ERR(scmi_get_protocol_instance(handle, protocol_id));
}
@@ -668,7 +668,7 @@ int scmi_acquire_protocol(struct scmi_handle *handle, u8
protocol_id)
* Remove one user for the specified protocol and triggers de-initialization
* and resources de-allocation once the last user has gone.
*/
-void scmi_release_protocol(struct scmi_handle *handle, u8 protocol_id)
+void scmi_release_protocol(const struct scmi_handle *handle, u8 protocol_id)
{
struct scmi_info *info = handle_to_scmi_info(handle);
struct scmi_protocol_instance *pi;
@@ -700,6 +700,29 @@ void scmi_release_protocol(struct scmi_handle *handle, u8
protocol_id)
mutex_unlock(&info->protocols_mtx);
}
+/**
+ * scmi_get_protocol_operations - Get protocol operations
+ * @handle: A reference to the SCMI platform instance.
+ * @protocol_id: The protocol being requested.
+ *
+ * Get hold of a protocol accounting for its usage, eventually triggering its
+ * initialization, and returning the protocol specific operations.
+ *
+ * Return: A reference to the requested protocol operations or error.
+ *Must be checked for errors by caller.
+ */
+static const void __must_check
+*scmi_get_protocol_operations(const struct scmi_handle *handle, u8 protocol_id)
+{
+ struct scmi_protocol_instance *pi;
+
+ pi = scmi_get_protocol_instance(handle, protocol_id);
+ if (IS_ERR(pi))
+ return pi;
+
+ return pi->proto->ops;
+} > +
void scmi_setup_protocol_implemented(const struct scmi_handle *handle,
u8 *prot_imp)
{
@@ -975,6 +998,8 @@ static int scmi_probe(struct platform_device *pdev)
handle = &info->handle;
handle->dev = info->dev;
handle->version = &info->version;
+ handle->get_ops = scmi_get_protocol_operations;
+ handle->put_ops = scmi_release_protocol;
Why do you need get_ops and put_ops? Why not have the drivers call
scmi_acquire_protocol and scmi_release_protocol directly and get the ops
from retrieved scmi_get_protocol_instance ? IMHO, this makes it more
readable. Also, this will make the usage of scmi_acquire_protocol and
scmi_release_protocol more consistent. Right now, notify.c uses
scmi_acquire_protocol to acquire protocol because there is no need for
ops and other drivers use get_ops to acquire protocol. Kind of confusing..
--
Warm Regards
Thara
ret = scmi_txrx_setup(info, dev, SCMI_PROTOCOL_BASE);
if (ret)
diff --git a/drivers/firmware/arm_scmi/notify.c
b/drivers/firmware/arm_scmi/notify.c
index eae58b2a92cc..02b00af9b08f 100644
--- a/drivers/firmware/arm_scmi/notify.c
+++ b/drivers/firmware/arm_scmi/notify.c
@@ -367,7 +367,7 @@ static struct scmi_event_handler *
scmi_get_active_handler(struct scmi_notify_instance *ni, u32 evt_key);
static void scmi_put_active_handler(struct scmi_notify_instance *ni,
struct scmi_event_handler *hndl);
-static void scmi_put_handler_unlocked(struct scmi_notify_instance *ni,
+static bool scmi_put_handler_unlocked(struct scmi_notify_instance *ni,
struct scmi_event_handler *hndl);
/**
@@ -899,9 +899,21 @@ static inline int scmi_bind_event_handler(struct
scmi_notify_instance *ni,
if (!r_evt)
return -EINVAL;
- /* Remove from pending and insert into registered */
+ /*
+* Remove
Re: [PATCH v3 1/2] dt-bindings: arm: cpus: Document 'qcom,freq-domain' property
Hi, Manivannan On Tue, 2020-10-20 at 21:09 +0530, Manivannan Sadhasivam wrote: > Add devicetree documentation for 'qcom,freq-domain' property specific > to Qualcomm CPUs. This property is used to reference the CPUFREQ node > along with Domain ID (0/1). > > Signed-off-by: Manivannan Sadhasivam > --- > Documentation/devicetree/bindings/arm/cpus.yaml | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml > b/Documentation/devicetree/bindings/arm/cpus.yaml > index 1222bf1831fa..f40564bf004f 100644 > --- a/Documentation/devicetree/bindings/arm/cpus.yaml > +++ b/Documentation/devicetree/bindings/arm/cpus.yaml > @@ -290,6 +290,12 @@ properties: > >* arm/msm/qcom,kpss-acc.txt > > + qcom,freq-domain: Do you mind to change "qcom, freq-domain" to common naming? or drop the prefix. So that we can use this CPU node and map it to each freq-domain. Thanks a lot. > +$ref: '/schemas/types.yaml#/definitions/phandle-array' > +description: | > + CPUs supporting freq-domain must set their "qcom,freq-domain" property > + with phandle to a cpufreq_hw node followed by the Domain ID(0/1). > + >rockchip,pmu: > $ref: '/schemas/types.yaml#/definitions/phandle' > description: |
Re: [PATCH v7 2/4] powerpc: Refactor kexec functions to move arch independent code to ima
On 10/20/20 1:01 PM, Mimi Zohar wrote: On Wed, 2020-09-30 at 13:59 -0700, Lakshmi Ramasubramanian wrote: The functions ima_get_kexec_buffer() and ima_free_kexec_buffer(), that handle carrying forward the IMA measurement logs on kexec for powerpc do not have architecture specific code, but they are currently defined for powerpc only. Move ima_get_kexec_buffer() and ima_free_kexec_buffer() to IMA subsystem. A later patch in this series will use these functions for carrying forward the IMA measurement log for ARM64. With the above refactoring arch/powerpc/kexec/ima.c contains only functions used when CONFIG_IMA_KEXEC is enabled. Update Makefile in arch/powerpc/kexec to include arch/powerpc/kexec/ima.c only when CONFIG_IMA_KEXEC is enabled. Move ima_dump_measurement_list() and ima_add_kexec_buffer() to a new file namely ima_kexec_fdt.c in IMA. Update security/integrity/ima/Makefile to include ima_kexec_fdt.c only when CONFIG_IMA_KEXEC is enabled. Co-developed-by: Prakhar Srivastava Signed-off-by: Prakhar Srivastava Signed-off-by: Lakshmi Ramasubramanian The existing support for carrying the IMA measurement list across kexec is limited to powerpc. This patch set is adding similar support for arm64, making as much of the existing code as generic as possible. However ima_dump_measurement_list() is already generic, but for some reason this patch moves it to ima_kexec_fdt.c. ima_kexec_fdt.c should be limited to device tree specific code. I wanted to split the functions defined under CONFIG_HAVE_IMA_KEXEC and CONFIG_IMA_KEXEC to separate files so that we can get rid of #ifdef in C file and instead conditionally compile the C files (using Makefile). ima_dump_measurement_list() need to be defined only when CONFIG_IMA_KEXEC is defined. I moved it to ima_kexec_fdt.c Instead of ima_kexec_fdt.c, where ima_dump_measurement_list() and ima_add_kexec_buffer() are defined, perhaps I can change the file name to "ima_kexec_buffer.c". Would that be better? This patch is probably doing the right thing, but the way the patch is formatted it replaces parts of a function with a different function. With the changes suggested above and in 1/4, the next version should be clearer. Like I'd stated above, I wanted to remove "#ifdef" from the C files and hence had to move some functions. But the functionalities haven't been changed. thanks, -lakshmi
Re: [MPTCP][PATCH net-next 0/2] init ahmac and port of mptcp_options_received
Hi Jakub, Jakub Kicinski 于2020年10月21日周三 上午7:39写道： > > On Mon, 19 Oct 2020 18:23:14 +0800 Geliang Tang wrote: > > This patchset deals with initializations of mptcp_options_received's two > > fields, ahmac and port. > > Applied, but two extra comments: > - please make sure the commit messages are in imperative form >e.g. "Initialize x..." rather than "This patches initializes x.." > - I dropped the Fixes tag from patch 2, and only queued patch 1 for >stable - patch 2 is a minor clean up, right? Yes, that's right. Thanks for applying and updating the patches. -Geliang > > Thanks!
[PATCH v2 6/6] dt-bindings: spi: Add compatible for Intel LGM SoC
From: Ramuthevar Vadivel Murugan Add compatible string for Intel LGM SoC. Signed-off-by: Ramuthevar Vadivel Murugan --- Documentation/devicetree/bindings/spi/cadence-quadspi.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml b/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml index 57be1a730e7b..44378d2d2b9e 100644 --- a/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml +++ b/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml @@ -19,6 +19,7 @@ properties: - const: cdns,qspi-nor - const: ti,k2g-qspi, cdns,qspi-nor - const: ti,am654-ospi, cdns,qspi-nor + - const: intel,lgm-qspi, cdns,qspi-nor reg: items: -- 2.11.0
[PATCH v2 3/6] spi: Move cadence-quadspi.txt to Documentation/devicetree/bindings/spi
From: Ramuthevar Vadivel Murugan
Move the Documentation/devicetree/bindings/mtd/cadence-quadspi.txt to
Documentation/devicetree/bindings/spi/
Signed-off-by: Ramuthevar Vadivel Murugan
---
Documentation/devicetree/bindings/{mtd => spi}/cadence-quadspi.txt | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/{mtd => spi}/cadence-quadspi.txt
(100%)
diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
b/Documentation/devicetree/bindings/spi/cadence-quadspi.txt
similarity index 100%
rename from Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
rename to Documentation/devicetree/bindings/spi/cadence-quadspi.txt
--
2.11.0
[PATCH v2 4/6] dt-bindings: spi: Convert cadence-quadspi.txt to cadence-quadspi.yaml
From: Ramuthevar Vadivel Murugan
Convert the cadence-quadspi.txt documentation to cadence-quadspi.yaml
remove the cadence-quadspi.txt from Documentation/devicetree/bindings/spi/
Signed-off-by: Ramuthevar Vadivel Murugan
Acked-by: Rob Herring
---
.../devicetree/bindings/spi/cadence-quadspi.txt| 67 --
.../devicetree/bindings/spi/cadence-quadspi.yaml | 148 +
2 files changed, 148 insertions(+), 67 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/spi/cadence-quadspi.txt
create mode 100644 Documentation/devicetree/bindings/spi/cadence-quadspi.yaml
diff --git a/Documentation/devicetree/bindings/spi/cadence-quadspi.txt
b/Documentation/devicetree/bindings/spi/cadence-quadspi.txt
deleted file mode 100644
index 945be7d5b236..
--- a/Documentation/devicetree/bindings/spi/cadence-quadspi.txt
+++ /dev/null
@@ -1,67 +0,0 @@
-* Cadence Quad SPI controller
-
-Required properties:
-- compatible : should be one of the following:
- Generic default - "cdns,qspi-nor".
- For TI 66AK2G SoC - "ti,k2g-qspi", "cdns,qspi-nor".
- For TI AM654 SoC - "ti,am654-ospi", "cdns,qspi-nor".
-- reg : Contains two entries, each of which is a tuple consisting of a
- physical address and length. The first entry is the address and
- length of the controller register set. The second entry is the
- address and length of the QSPI Controller data area.
-- interrupts : Unit interrupt specifier for the controller interrupt.
-- clocks : phandle to the Quad SPI clock.
-- cdns,fifo-depth : Size of the data FIFO in words.
-- cdns,fifo-width : Bus width of the data FIFO in bytes.
-- cdns,trigger-address : 32-bit indirect AHB trigger address.
-
-Optional properties:
-- cdns,is-decoded-cs : Flag to indicate whether decoder is used or not.
-- cdns,rclk-en : Flag to indicate that QSPI return clock is used to latch
- the read data rather than the QSPI clock. Make sure that QSPI return
- clock is populated on the board before using this property.
-
-Optional subnodes:
-Subnodes of the Cadence Quad SPI controller are spi slave nodes with additional
-custom properties:
-- cdns,read-delay : Delay for read capture logic, in clock cycles
-- cdns,tshsl-ns : Delay in nanoseconds for the length that the master
- mode chip select outputs are de-asserted between
- transactions.
-- cdns,tsd2d-ns : Delay in nanoseconds between one chip select being
- de-activated and the activation of another.
-- cdns,tchsh-ns : Delay in nanoseconds between last bit of current
- transaction and deasserting the device chip select
- (qspi_n_ss_out).
-- cdns,tslch-ns : Delay in nanoseconds between setting qspi_n_ss_out low
- and first bit transfer.
-- resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : Must include either "qspi" and/or "qspi-ocp".
-
-Example:
-
- qspi: spi@ff705000 {
- compatible = "cdns,qspi-nor";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0xff705000 0x1000>,
- <0xffa0 0x1000>;
- interrupts = <0 151 4>;
- clocks = <&qspi_clk>;
- cdns,is-decoded-cs;
- cdns,fifo-depth = <128>;
- cdns,fifo-width = <4>;
- cdns,trigger-address = <0x>;
- resets = <&rst QSPI_RESET>, <&rst QSPI_OCP_RESET>;
- reset-names = "qspi", "qspi-ocp";
-
- flash0: n25q00@0 {
- ...
- cdns,read-delay = <4>;
- cdns,tshsl-ns = <50>;
- cdns,tsd2d-ns = <50>;
- cdns,tchsh-ns = <4>;
- cdns,tslch-ns = <4>;
- };
- };
diff --git a/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml
b/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml
new file mode 100644
index ..6ed8122a1326
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml
@@ -0,0 +1,148 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/cadence-quadspi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cadence Quad SPI controller
+
+maintainers:
+ - Vadivel Murugan
+
+allOf:
+ - $ref: "spi-controller.yaml#"
+
+properties:
+ compatible:
+items:
+ - const: cdns,qspi-nor
+ - const: ti,k2g-qspi, cdns,qspi-nor
+ - const: ti,am654-ospi, cdns,qspi-nor
+
+description:
+ Should be one of the above supported compatible strings.
+ optional properties
+ "cdns,is-decoded-cs" - Flag to indicate whether decoder is used or not.
+ "cdns,rclk-en" - Flag to indicate that QSPI return clock is used to latch
+ the read data rather th
[PATCH v2 2/6] spi: cadence-quadspi: Add multi-chipselect support for Intel LGM SoC
From: Ramuthevar Vadivel Murugan
Add multiple chipselect support for Intel LGM SoCs,
currently QSPI-NOR and QSPI-NAND supported.
Signed-off-by: Ramuthevar Vadivel Murugan
---
drivers/spi/spi-cadence-quadspi.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/spi/spi-cadence-quadspi.c
b/drivers/spi/spi-cadence-quadspi.c
index 3d017b484114..3bf6d3697631 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -38,6 +38,7 @@
/* Capabilities */
#define CQSPI_SUPPORTS_OCTAL BIT(0)
+#define CQSPI_SUPPORTS_MULTI_CHIPSELECT BIT(1)
struct cqspi_st;
@@ -75,6 +76,7 @@ struct cqspi_st {
boolis_decoded_cs;
u32 fifo_depth;
u32 fifo_width;
+ u32 num_chipselect;
boolrclk_en;
u32 trigger_address;
u32 wr_delay;
@@ -1070,6 +1072,14 @@ static int cqspi_of_get_pdata(struct cqspi_st *cqspi)
return -ENXIO;
}
+ if (!cqspi->use_direct_mode) {
+ if (of_property_read_u32(np, "num-chipselect",
+&cqspi->num_chipselect)) {
+ dev_err(dev, "couldn't determine number of cs\n");
+ return -ENXIO;
+ }
+ }
+
cqspi->rclk_en = of_property_read_bool(np, "cdns,rclk-en");
return 0;
@@ -1307,6 +1317,9 @@ static int cqspi_probe(struct platform_device *pdev)
cqspi->current_cs = -1;
cqspi->sclk = 0;
+ if (ddata->hwcaps_mask & CQSPI_SUPPORTS_MULTI_CHIPSELECT)
+ master->num_chipselect = cqspi->num_chipselect;
+
ret = cqspi_setup_flash(cqspi);
if (ret) {
dev_err(dev, "failed to setup flash parameters %d\n", ret);
@@ -1396,6 +1409,7 @@ static const struct cqspi_driver_platdata am654_ospi = {
};
static const struct cqspi_driver_platdata intel_lgm_qspi = {
+ .hwcaps_mask = CQSPI_SUPPORTS_MULTI_CHIPSELECT,
.quirks = CQSPI_DISABLE_DAC_MODE,
};
--
2.11.0
[PATCH v2 5/6] dt-bindings: spi: Add compatible for Intel LGM SoC
From: Ramuthevar Vadivel Murugan
Add compatible string for Intel LGM SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
---
.../devicetree/bindings/spi/cadence-quadspi.yaml | 68 +++---
1 file changed, 34 insertions(+), 34 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml
b/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml
index 6ed8122a1326..57be1a730e7b 100644
--- a/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml
+++ b/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml
@@ -14,65 +14,61 @@ allOf:
properties:
compatible:
-items:
- - const: cdns,qspi-nor
- - const: ti,k2g-qspi, cdns,qspi-nor
- - const: ti,am654-ospi, cdns,qspi-nor
-
-description:
- Should be one of the above supported compatible strings.
- optional properties
- "cdns,is-decoded-cs" - Flag to indicate whether decoder is used or not.
- "cdns,rclk-en" - Flag to indicate that QSPI return clock is used to latch
- the read data rather than the QSPI clock. Make sure that QSPI return
- clock is populated on the board before using this property.
+oneOf:
+ - items:
+ - const: cdns,qspi-nor
+ - const: ti,k2g-qspi, cdns,qspi-nor
+ - const: ti,am654-ospi, cdns,qspi-nor
reg:
-maxItems: 2
-
-description:
- Contains two entries, each of which is a tuple consisting of a
- physical address and length. The first entry is the address and
- length of the controller register set. The second entry is the
- address and length of the QSPI Controller data area.
+items:
+ - description: the controller register set
+ - description: the controller data area
interrupts:
maxItems: 1
-description:
- Unit interrupt specifier for the controller interrupt.
clocks:
maxItems: 1
-description:
- phandle to the Quad SPI clock.
cdns,fifo-depth:
description:
Size of the data FIFO in words.
-allOf:
- - $ref: "/schemas/types.yaml#/definitions/uint32"
- - enum: [ 128, 256 ]
- - default: 128
+$ref: "/schemas/types.yaml#/definitions/uint32"
+enum: [ 128, 256 ]
+default: 128
cdns,fifo-width:
$ref: /schemas/types.yaml#/definitions/uint32
description:
Bus width of the data FIFO in bytes.
-multipleOf: 4
+default: 4
cdns,trigger-address:
$ref: /schemas/types.yaml#/definitions/uint32
description:
32-bit indirect AHB trigger address.
+ cdns,is-decoded-cs:
+type: boolean
+description:
+ Flag to indicate whether decoder is used or not.
+
+ cdns,rclk-en:
+type: boolean
+description:
+ Flag to indicate that QSPI return clock is used to latch the read
+ data rather than the QSPI clock. Make sure that QSPI return clock
+ is populated on the board before using this property.
+
resets:
- description:
- Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
+maxItems : 2
reset-names:
-description:
- Must include either "qspi" and/or "qspi-ocp".
+minItems: 1
+maxItems: 2
+items:
+ enum: [ qspi, qspi-ocp ]
# subnode's properties
patternProperties:
@@ -114,13 +110,17 @@ required:
- cdns,fifo-depth
- cdns,fifo-width
- cdns,trigger-address
+ - cdns,is-decoded-cs
+ - cdns,rclk-en
- resets
- reset-names
+additionalProperties: false
+
examples:
- |
qspi: spi@ff705000 {
- compatible = "cadence,qspi";
+ compatible = "cadence,qspi","cdns,qpsi-nor";
#address-cells = <1>;
#size-cells = <0>;
reg = <0xff705000 0x1000>,
--
2.11.0
[PATCH v2 0/6] spi: cadence-quadspi: Add QSPI controller support for Intel LGM SoC
Add QSPI controller support for Intel LGM SoC. Note from Vignesh(mtd subsystem maintainer): This series is a subset of "[PATCH v12 0/4] spi: cadence-quadspi: Add support for the Cadence QSPI controller" by Ramuthevar,Vadivel MuruganX that intended to move cadence-quadspi driver to spi-mem framework Those patches were trying to accomplish too many things in a single set of patches and need to split into smaller patches. This is reduced version of above series. Changes that are intended to make migration easy are split into separate patches. Patches 1 to 3 drop features that cannot be supported under spi-mem at the moment (backward compatibility is maintained). Patch 4-5 are trivial cleanups. Patch 6 does the actual conversion to spi-mem and patch 7 moves the driver to drivers/spi folder. I have tested both INDAC mode (used by non TI platforms like Altera SoCFPGA) and DAC mode (used by TI platforms) on TI EVMs. Patches to move move bindings over to "Documentation/devicetree/bindings/spi/" directory and also conversion of bindig doc to YAML will be posted separately. Support for Intel platform would follow that. Reference: https://lkml.org/lkml/2020/6/1/50 --- v2: - Rob's review comments update for dt-bindings - add 'oneOf' for compatible selection - drop un-neccessary descriptions - add the cdns,is-decoded-cs and cdns,rclk-en properties as schema - remove 'allOf' in not required place - add AdditionalProperties false - add minItems/maxItems for qspi reset attributes resend-v1: - As per Mark's suggestion , reorder the patch series 1-3 driver support patches, series 4-6 dt-bindings patches. v1: - initial version Ramuthevar Vadivel Murugan (6): spi: cadence-quadspi: Disable the DAC for Intel LGM SoC spi: cadence-quadspi: Add multi-chipselect support for Intel LGM SoC spi: Move cadence-quadspi.txt to Documentation/devicetree/bindings/spi dt-bindings: spi: Convert cadence-quadspi.txt to cadence-quadspi.yaml dt-bindings: spi: Add compatible for Intel LGM SoC dt-bindings: spi: Add compatible for Intel LGM SoC .../devicetree/bindings/mtd/cadence-quadspi.txt| 67 - .../devicetree/bindings/spi/cadence-quadspi.yaml | 149 + drivers/spi/spi-cadence-quadspi.c | 26 3 files changed, 175 insertions(+), 67 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mtd/cadence-quadspi.txt create mode 100644 Documentation/devicetree/bindings/spi/cadence-quadspi.yaml -- 2.11.0
