summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-12-04Merge tag 'dt-cleanup-6.2-2' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-dt into soc/dt Minor improvements in ARM DTS for v6.2, part two Few cleanups which should not have any functional impact: 1. Trim addresses in "reg" to 8 digits. 2. Align LED node names with dtschema. 3. omap: echo: Use preferred enable-gpios property for LP5523 LED. * tag 'dt-cleanup-6.2-2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-dt: ARM: dts: sti: align LED node names with dtschema ARM: dts: am335x: align LED node names with dtschema ARM: dts: omap: echo: use preferred enable-gpios for LP5523 LED ARM: dts: omap: align LED node names with dtschema ARM: dts: logicpd: align LED node names with dtschema ARM: dts: lpc32xx: trim addresses to 8 digits ARM: dts: imx: trim addresses to 8 digits ARM: dts: omap: trim addresses to 8 digits Link: https://lore.kernel.org/r/20221204082909.5649-1-krzysztof.kozlowski@linaro.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-12-04Merge tag 'asahi-soc-dt-6.2-v2' of https://github.com/AsahiLinux/linux into ↵Arnd Bergmann
soc/dt Apple SoC DT updates for 6.2 (v2). This includes: * L1/L2 cache topology for t600x * CPUfreq nodes for t8103/t600x * DT binding for CPUfreq * Associated MAINTAINERS update The CPUfreq driver was already merged for 6.2 via its tree. * tag 'asahi-soc-dt-6.2-v2' of https://github.com/AsahiLinux/linux: arm64: dts: apple: Add CPU topology & cpufreq nodes for t600x arm64: dts: apple: Add CPU topology & cpufreq nodes for t8103 dt-bindings: cpufreq: apple,soc-cpufreq: Add binding for Apple SoC cpufreq MAINTAINERS: Add entries for Apple SoC cpufreq driver arm64: dts: apple: Add t600x L1/L2 cache properties and nodes Link: https://lore.kernel.org/r/a9353121-7fed-fde7-6f40-939a65bfeefb@marcan.st Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-12-04arm64: dts: apple: Add CPU topology & cpufreq nodes for t600xHector Martin
Add the missing CPU topology/capacity information and the cpufreq nodes, so we can have CPU frequency scaling and the scheduler has the information it needs to make the correct decisions. As with t8103, boost states are commented out pending PSCI/etc support for deep sleep states. Reviewed-by: Sven Peter <sven@svenpeter.dev> Signed-off-by: Hector Martin <marcan@marcan.st>
2022-12-03tools/testing/cxl: Add XOR Math support to cxl_testAlison Schofield
Expand the cxl_test topology to include CFMWS's that use XOR math for interleave arithmetic, as defined in the CXL Specification 3.0. With this expanded topology, cxl_test is useful for testing: x1,x2,x4 ways with XOR interleave arithmetic. Define the additional XOR CFMWS entries to appear only with the module parameter interleave_arithmetic=1. The cxl_test default continues to be modulo math. modprobe cxl_test interleave_arithmetic=1 Signed-off-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/54670400cd48ba7fcc6d8ee0d6ae2276d3f51aad.1669847017.git.alison.schofield@intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2022-12-04rust: types: add `Opaque` typeWedson Almeida Filho
Add the `Opaque` type, which is meant to be used with FFI objects that are never interpreted by Rust code, e.g.: struct Waiter { completion: Opaque<bindings::completion>, next: *mut Waiter, } It has the advantage that the objects don't have to be zero-initialised before calling their init functions, making the code performance closer to C. Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: types: add `Either` typeWedson Almeida Filho
Introduce the new `types` module of the `kernel` crate with `Either` as its first type. `Either<L, R>` is a sum type that always holds either a value of type `L` (`Left` variant) or `R` (`Right` variant). For instance: struct Executor { queue: Either<BoxedQueue, &'static Queue>, } Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> Reviewed-by: Wei Liu <wei.liu@kernel.org> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: build_assert: add `build_{error,assert}!` macrosGary Guo
Add the `build_error!` and `build_assert!` macros which leverage the previously introduced `build_error` crate. Do so in a new module, called `build_assert`. The former fails the build if the code path calling it can possibly be executed. The latter asserts that a boolean expression is `true` at compile time. In particular, `build_assert!` can be used in some contexts where `static_assert!` cannot: fn f1<const N: usize>() { static_assert!(N > 1);` // Error. build_assert!(N > 1); // Build-time check. assert!(N > 1); // Run-time check. } #[inline] fn f2(n: usize) { static_assert!(n > 1); // Error. build_assert!(n > 1); // Build-time check. assert!(n > 1); // Run-time check. } Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Wei Liu <wei.liu@kernel.org> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: add `build_error` crateGary Guo
The `build_error` crate provides a function `build_error` which will panic at compile-time if executed in const context and, by default, will cause a build error if not executed at compile time and the optimizer does not optimise away the call. The `CONFIG_RUST_BUILD_ASSERT_ALLOW` kernel option allows to relax the default build failure and convert it to a runtime check. If the runtime check fails, `panic!` will be called. Its functionality will be exposed to users as a couple macros in the `kernel` crate in the following patch, thus some documentation here refers to them for simplicity. Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Wei Liu <wei.liu@kernel.org> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: static_assert: add `static_assert!` macroMiguel Ojeda
Add the `static_assert!` macro, which is a compile-time assert, similar to the C11 `_Static_assert` and C++11 `static_assert` declarations [1,2]. Do so in a new module, called `static_assert`. For instance: static_assert!(42 > 24); static_assert!(core::mem::size_of::<u8>() == 1); const X: &[u8] = b"bar"; static_assert!(X[1] == b'a'); const fn f(x: i32) -> i32 { x + 2 } static_assert!(f(40) == 42); Link: https://en.cppreference.com/w/c/language/_Static_assert [1] Link: https://en.cppreference.com/w/cpp/language/static_assert [2] Co-developed-by: Alex Gaynor <alex.gaynor@gmail.com> Signed-off-by: Alex Gaynor <alex.gaynor@gmail.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: std_vendor: add `dbg!` macro based on `std`'s oneNiklas Mohrin
The Rust standard library has a really handy macro, `dbg!` [1,2]. It prints the source location (filename and line) along with the raw source code that is invoked with and the `Debug` representation of the given expression, e.g.: let a = 2; let b = dbg!(a * 2) + 1; // ^-- prints: [src/main.rs:2] a * 2 = 4 assert_eq!(b, 5); Port the macro over to the `kernel` crate inside a new module called `std_vendor`, using `pr_info!` instead of `eprintln!` and make the rules about committing uses of `dbg!` into version control more concrete (i.e. tailored for the kernel). Since the source code for the macro is taken from the standard library source (with only minor adjustments), the new file is licensed under `Apache 2.0 OR MIT`, just like the original [3,4]. Link: https://doc.rust-lang.org/std/macro.dbg.html [1] Link: https://github.com/rust-lang/rust/blob/master/library/std/src/macros.rs#L212 [2] Link: https://github.com/rust-lang/rust/blob/master/library/std/Cargo.toml [3] Link: https://github.com/rust-lang/rust/blob/master/COPYRIGHT [4] Signed-off-by: Niklas Mohrin <dev@niklasmohrin.de> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: str: add `fmt!` macroWedson Almeida Filho
Add the `fmt!` macro, which is a convenience alias for the Rust `core::format_args!` macro. For instance, it may be used to create a `CString`: CString::try_from_fmt(fmt!("{}{}", "abc", 42))? Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: str: add `CString` typeWedson Almeida Filho
Add the `CString` type, which is an owned string that is guaranteed to have exactly one `NUL` byte at the end, i.e. the owned equivalent to `CStr` introduced earlier. It is used for interoperability with kernel APIs that take C strings. In order to do so, implement the `RawFormatter::new()` constructor and the `RawFormatter::bytes_written()` method as well. Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: str: add `Formatter` typeWedson Almeida Filho
Add the `Formatter` type, which leverages `RawFormatter`, but fails if callers attempt to write more than will fit in the buffer. In order to so, implement the `RawFormatter::from_buffer()` constructor as well. Co-developed-by: Adam Bratschi-Kaye <ark.email@gmail.com> Signed-off-by: Adam Bratschi-Kaye <ark.email@gmail.com> Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: str: add `c_str!` macroGary Guo
Add `c_str!`, which is a convenience macro that creates a new `CStr` from a string literal. It is designed to be similar to a `str` in usage, and it is usable in const contexts, for instance: const X: &CStr = c_str!("Example"); Co-developed-by: Alex Gaynor <alex.gaynor@gmail.com> Signed-off-by: Alex Gaynor <alex.gaynor@gmail.com> Signed-off-by: Gary Guo <gary@garyguo.net> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: str: add `CStr` unit testsMilan Landaverde
Add unit tests for `CStr::from_bytes_with_nul()` and `CStr::from_bytes_with_nul_unchecked()`. These serve as an example of the first unit tests for Rust code (i.e. different from documentation tests). Signed-off-by: Milan Landaverde <milan@mdaverde.com> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: str: implement several traits for `CStr`Gary Guo
Implement `Debug`, `Display`, `Deref` (into `BStr`), `AsRef<BStr>` and a set of `Index<...>` traits. This makes it `CStr` more convenient to use (and closer to `str`). Co-developed-by: Alex Gaynor <alex.gaynor@gmail.com> Signed-off-by: Alex Gaynor <alex.gaynor@gmail.com> Co-developed-by: Morgan Bartlett <mjmouse9999@gmail.com> Signed-off-by: Morgan Bartlett <mjmouse9999@gmail.com> Signed-off-by: Gary Guo <gary@garyguo.net> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: str: add `CStr` typeGary Guo
Add the `CStr` type, which is a borrowed string that is guaranteed to have exactly one `NUL` byte, which is at the end. It is used for interoperability with kernel APIs that take C strings. Add it to the prelude too. Co-developed-by: Alex Gaynor <alex.gaynor@gmail.com> Signed-off-by: Alex Gaynor <alex.gaynor@gmail.com> Co-developed-by: Milan Landaverde <milan@mdaverde.com> Signed-off-by: Milan Landaverde <milan@mdaverde.com> Signed-off-by: Gary Guo <gary@garyguo.net> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: str: add `b_str!` macroGary Guo
Add the `b_str!` macro, which creates a new `BStr` from a string literal. It is usable in const contexts, for instance: const X: &BStr = b_str!("Example"); Signed-off-by: Gary Guo <gary@garyguo.net> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: str: add `BStr` typeGary Guo
Add the `BStr` type, which is a byte string without UTF-8 validity guarantee. It is simply an alias to `[u8]`, but has a more evident semantical meaning. Signed-off-by: Gary Guo <gary@garyguo.net> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: alloc: add `Vec::try_with_capacity{,_in}()` constructorsMiguel Ojeda
Add `Vec::try_with_capacity()` and `Vec::try_with_capacity_in()` as the fallible versions of `Vec::with_capacity()` and `Vec::with_capacity_in()`, respectively. The implementations follow the originals and use the previously added `RawVec::try_with_capacity_in()`. In turn, `Vec::try_with_capacity()` will be used to implement the `CString` type (which wraps a `Vec<u8>`) in a later patch. Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: alloc: add `RawVec::try_with_capacity_in()` constructorMiguel Ojeda
Add the `RawVec::try_with_capacity_in()` constructor as the fallible version of `RawVec::with_capacity_in()`. The implementation follows the original. The infallible constructor is implemented in terms of the private `RawVec::allocate_in()` constructor, thus also add the private `RawVec::try_allocate_in()` constructor following the other. It will be used to implement `Vec::try_with_capacity{,_in}()` in the next patch. Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: prelude: add `error::code::*` constant itemsWedson Almeida Filho
It is convenient to have all the `Error` constant items (such as `EINVAL`) available as-is everywhere (i.e. for code using the kernel prelude such as kernel modules). Therefore, add all of them to the prelude. For instance, this allows to write `Err(EINVAL)` to create a kernel `Result`: fn f() -> Result<...> { ... Err(EINVAL) } Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: error: add `From` implementations for `Error`Wedson Almeida Filho
Add a set of `From` implementations for the `Error` kernel type. These implementations allow to easily convert from standard Rust error types to the usual kernel errors based on one of the `E*` integer codes. On top of that, the question mark Rust operator (`?`) implicitly performs a conversion on the error value using the `From` trait when propagating. Thus it is extra convenient to use. For instance, a kernel function that needs to convert a `i64` into a `i32` and to bubble up the error as a kernel error may write: fn f(x: i64) -> Result<...> { ... let y = i32::try_from(x)?; ... } which will transform the `TryFromIntError` into an `Err(EINVAL)`. Co-developed-by: Adam Bratschi-Kaye <ark.email@gmail.com> Signed-off-by: Adam Bratschi-Kaye <ark.email@gmail.com> Co-developed-by: Nándor István Krácser <bonifaido@gmail.com> Signed-off-by: Nándor István Krácser <bonifaido@gmail.com> Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> Reviewed-by: Finn Behrens <me@kloenk.dev> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: error: add codes from `errno-base.h`Viktor Garske
Only a few codes were added so far. With the `declare_err!` macro in place, add the remaining ones (which is most of them) from `include/uapi/asm-generic/errno-base.h`. Co-developed-by: Wedson Almeida Filho <wedsonaf@gmail.com> Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> Signed-off-by: Viktor Garske <viktor@v-gar.de> Reviewed-by: Gary Guo <gary@garyguo.net> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: error: declare errors using macroFinn Behrens
Add a macro to declare errors, which simplifies the work needed to add each one, avoids repetition of the code and makes it easier to change the way they are declared. Signed-off-by: Finn Behrens <me@kloenk.dev> Reviewed-by: Gary Guo <gary@garyguo.net> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: macros: take string literals in `module!`Gary Guo
Instead of taking binary string literals, take string ones instead, making it easier for users to define a module, i.e. instead of calling `module!` like: module! { ... name: b"rust_minimal", ... } now it is called as: module! { ... name: "rust_minimal", ... } Module names, aliases and license strings are restricted to ASCII only. However, the author and the description allows UTF-8. For simplicity (avoid parsing), escape sequences and raw string literals are not yet handled. Link: https://github.com/Rust-for-Linux/linux/issues/252 Link: https://lore.kernel.org/lkml/YukvvPOOu8uZl7+n@yadro.com/ Signed-off-by: Gary Guo <gary@garyguo.net> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: macros: add `#[vtable]` proc macroGary Guo
This procedural macro attribute provides a simple way to declare a trait with a set of operations that later users can partially implement, providing compile-time `HAS_*` boolean associated constants that indicate whether a particular operation was overridden. This is useful as the Rust counterpart to structs like `file_operations` where some pointers may be `NULL`, indicating an operation is not provided. For instance: #[vtable] trait Operations { fn read(...) -> Result<usize> { Err(EINVAL) } fn write(...) -> Result<usize> { Err(EINVAL) } } #[vtable] impl Operations for S { fn read(...) -> Result<usize> { ... } } assert_eq!(<S as Operations>::HAS_READ, true); assert_eq!(<S as Operations>::HAS_WRITE, false); Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Sergio González Collado <sergio.collado@gmail.com> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: macros: add `concat_idents!` proc macroBjörn Roy Baron
This macro provides similar functionality to the unstable feature `concat_idents` without having to rely on it. For instance: let x_1 = 42; let x_2 = concat_idents!(x, _1); assert!(x_1 == x_2); It has different behavior with respect to macro hygiene. Unlike the unstable `concat_idents!` macro, it allows, for example, referring to local variables by taking the span of the second macro as span for the output identifier. Signed-off-by: Björn Roy Baron <bjorn3_gh@protonmail.com> Reviewed-by: Finn Behrens <me@kloenk.dev> Reviewed-by: Gary Guo <gary@garyguo.net> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-03cxl/acpi: Support CXL XOR Interleave Math (CXIMS)Alison Schofield
When the CFMWS is using XOR math, parse the corresponding CXIMS structure and store the xormaps in the root decoder structure. Use the xormaps in a new lookup, cxl_hb_xor(), to find a targets entry in the host bridge interleave target list. Defined in CXL Specfication 3.0 Section: 9.17.1 Signed-off-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/5794813acdf7b67cfba3609c6aaff46932fa38d0.1669847017.git.alison.schofield@intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2022-12-03Merge "ACPICA: Add CXL 3.0 structures..." into for-6.2/cxl-xorDan Williams
Pick up: f350c68e3cd5 ("ACPICA: Add CXL 3.0 structures (CXIMS & RDPAS) to the CEDT table") ...to build the new XOR interleave math support for the CXL Fixed Memory Window Structures.
2022-12-03Merge tag 'i2c-for-6.1-rc8' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: "A power state fix in the core for ACPI devices, a regression fix regarding bus recovery for the cadence driver, a DMA handling fix for the imx driver, and two error path fixes (npcm7xx and qcom-geni)" * tag 'i2c-for-6.1-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: imx: Only DMA messages with I2C_M_DMA_SAFE flag set i2c: qcom-geni: fix error return code in geni_i2c_gpi_xfer i2c: cadence: Fix regression with bus recovery i2c: Restore initial power state if probe fails i2c: npcm7xx: Fix error handling in npcm_i2c_init()
2022-12-03Merge tag 'dax-fixes-6.1-rc8' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm Pull dax fixes from Dan Williams: "A few bug fixes around the handling of "Soft Reserved" memory and memory tiering information. Linux is starting to enounter more real world systems that deploy an ACPI HMAT to describe different performance classes of memory, as well the "special purpose" (Linux "Soft Reserved") designation from EFI. These fixes result from that testing. It has all appeared in -next for a while with no known issues. - Fix duplicate overlapping device-dax instances for HMAT described "Soft Reserved" Memory - Fix missing node targets in the sysfs representation of memory tiers - Remove a confusing variable initialization" * tag 'dax-fixes-6.1-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: device-dax: Fix duplicate 'hmem' device registration ACPI: HMAT: Fix initiator registration for single-initiator systems ACPI: HMAT: remove unnecessary variable initialization
2022-12-03cxl/pci: Add callback to log AER correctable errorDave Jiang
Add AER error handler callback to read the RAS capability structure correctable error (CE) status register for the CXL device. Log the error as a trace event and clear the error. For CXL devices, the driver also needs to write back to the status register to clear the unmasked correctable errors. See CXL spec rev3.0 8.2.4.16 for RAS capability structure CE Status Register. Suggested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/166985287203.2871899.13605149073500556137.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2022-12-03PCI/AER: Add optional logging callback for correctable errorDave Jiang
Some new devices such as CXL devices may want to record additional error information on a corrected error. Add a callback to allow the PCI device driver to do additional logging such as providing additional stats for user space RAS monitoring. For CXL device, this is actually a need due to CXL needing to write to the CXL RAS capability structure correctable error status register in order to clear the unmasked correctable errors. See CXL spec rev3.0 8.2.4.16. Suggested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/166984619233.2804404.3966368388544312674.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2022-12-03cxl/pci: Add (hopeful) error handling supportDan Williams
Add nominal error handling that tears down CXL.mem in response to error notifications that imply a device reset. Given some CXL.mem may be operating as System RAM, there is a high likelihood that these error events are fatal. However, if the system survives the notification the expectation is that the driver behavior is equivalent to a hot-unplug and re-plug of an endpoint. Note that this does not change the mask values from the default. That awaits CXL _OSC support to determine whether platform firmware is in control of the mask registers. Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/166974413966.1608150.15522782911404473932.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2022-12-03cxl/pci: add tracepoint events for CXL RASDave Jiang
Add tracepoint events for recording the CXL uncorrectable and correctable errors. For uncorrectable errors, there is additional data of 512B from the header log register (CXL spec rev3 8.2.4.16.7). The trace event will intake a dynamic array that will dump the entire Header Log data. If multiple errors are set in the status register, then the 'first error' field (CXL spec rev3 v8.2.4.16.6) is read from the Error Capabilities and Control Register in order to determine the error. This implementation does not include CXL IDE Error details. Cc: Steven Rostedt <rostedt@goodmis.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org> Link: https://lore.kernel.org/r/166974413388.1608150.5875712482260436188.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2022-12-03cxl/pci: Find and map the RAS Capability StructureDan Williams
The RAS Capability Structure has some ancillary information that may be relevant with respect to AER events, link and protcol error status registers. Map the RAS Capability Registers in support of defining a 'struct pci_error_handlers' instance for the cxl_pci driver. Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/166974412803.1608150.7096566580400947001.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2022-12-03cxl/pci: Prepare for mapping RAS Capability StructureDan Williams
The RAS Capabilitiy Structure is a CXL Component register capability block. Unlike the HDM Decoder Capability, it will be referenced by the cxl_pci driver in response to PCIe AER events. Due to this it is no longer the case that cxl_map_component_regs() can assume that it should map all component registers. Plumb a bitmask of capability ids to map through cxl_map_component_regs(). For symmetry cxl_probe_device_regs() is updated to populate @id in 'struct cxl_reg_map' even though cxl_map_device_regs() does not have a need to map a subset of the device registers per caller. Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/166974412214.1608150.11487843455070795378.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2022-12-03cxl/port: Limit the port driver to just the HDM Decoder CapabilityDan Williams
Update the port driver to use cxl_map_component_registers() so that the component register block can be shared between the cxl_pci driver and the cxl_port driver. I.e. stop the port driver from reserving the entire component register block for itself via request_region() when it only needs the HDM Decoder Capability subset. Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/166974411625.1608150.7149373371599960307.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2022-12-03cxl/core/regs: Make cxl_map_{component, device}_regs() device genericDan Williams
There is no need to carry the barno and the block offset through the stack, just convert them to a resource base immediately. Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/166974411035.1608150.8605988708101648442.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2022-12-03cxl/pci: Kill cxl_map_regs()Dan Williams
The component registers are currently unused by the cxl_pci driver. Only the physical address base of the component registers is conveyed to the cxl_mem driver. Just call cxl_map_device_registers() directly. Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/166974410443.1608150.15855499736133349600.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2022-12-03cxl/pci: Cleanup cxl_map_device_regs()Dan Williams
Use a loop to reduce the duplicated code in cxl_map_device_regs(). This is in preparation for deleting cxl_map_regs(). Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/166974409867.1608150.14886452053935226038.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2022-12-03cxl/pci: Cleanup repeated code in cxl_probe_regs() helpersDan Williams
Rather then duplicating the setting of valid, length, and offset for each type, just convey a pointer to the register map to common code. Yes, the change in cxl_probe_component_regs() does not save any lines of code, but it is preparation for adding another component register type to map (RAS Capability Structure). Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/166974409293.1608150.17661353937678581423.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2022-12-03block: remove devnode callback from struct block_device_operationsGreg Kroah-Hartman
With the removal of the pktcdvd driver, there are no in-kernel users of the devnode callback in struct block_device_operations, so it can be safely removed. If it is needed for new block drivers in the future, it can be brought back. Cc: Jens Axboe <axboe@kernel.dk> Cc: linux-block@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20221203140747.1942969-1-gregkh@linuxfoundation.org Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-12-03docs/sp_SP: Add memory-barriers.txt Spanish translationCarlos Bilbao
Translate the following documents into Spanish: - memory-barriers.txt using the wrapper documents system. Signed-off-by: Carlos Bilbao <carlos.bilbao@amd.com> Link: https://lore.kernel.org/r/20221128152323.4080455-1-carlos.bilbao@amd.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2022-12-03docs/zh_CN/LoongArch: Update links of LoongArch ISA Vol1 and ELF psABITiezhu Yang
The current links of LoongArch ISA Vol1 and ELF psABI are invalid, the latest versions are 1.02 and 2.00 respectively, let us update the links. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Link: https://lore.kernel.org/r/1669892345-7763-3-git-send-email-yangtiezhu@loongson.cn Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2022-12-03docs/LoongArch: Update links of LoongArch ISA Vol1 and ELF psABITiezhu Yang
The current links of LoongArch ISA Vol1 and ELF psABI are invalid, the latest versions are 1.02 and 2.00 respectively, let us update the links. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Link: https://lore.kernel.org/r/1669892345-7763-2-git-send-email-yangtiezhu@loongson.cn Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2022-12-03Documentation/features: Update feature lists for 6.1Wei Li
Run the refresh script to document the recent feature additions on loong, um and csky as of v6.1-rc7. Signed-off-by: Wei Li <liwei391@huawei.com> Link: https://lore.kernel.org/r/20221203093750.4145802-1-liwei391@huawei.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2022-12-03Documentation: Fixed a typo in bootconfig.rstKushagra Verma
Fixed a typo in the word 'concatenated'. Signed-off-by: Kushagra Verma <kushagra765@outlook.com> Link: https://lore.kernel.org/r/HK0PR01MB2801DA243B726141A97FE92EF8179@HK0PR01MB2801.apcprd01.prod.exchangelabs.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2022-12-03dt-bindings: pinctrl: st,stm32: Deprecate pins-are-numberedBernhard Rosenkränzer
Deprecate the pins-are-numbered property Signed-off-by: Bernhard Rosenkränzer <bero@baylibre.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20221129023401.278780-5-bero@baylibre.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>