summaryrefslogtreecommitdiffstats
path: root/tools/perf/MANIFEST (unfollow)
Commit message (Collapse)AuthorFilesLines
2024-11-25x86: fix off-by-one in access_ok()David Laight1-2/+2
When the size isn't a small constant, __access_ok() will call valid_user_address() with the address after the last byte of the user buffer. It is valid for a buffer to end with the last valid user address so valid_user_address() must allow accesses to the base of the guard page. [ This introduces an off-by-one in the other direction for the plain non-sized accesses, but since we have that guard region that is a whole page, those checks "allowing" accesses to that guard region don't really matter. The access will fault anyway, whether to the guard page or if the address has been masked to all ones - Linus ] Fixes: 86e6b1547b3d0 ("x86: fix user address masking non-canonical speculation issue") Signed-off-by: David Laight <david.laight@aculab.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-11-25futex: improve user space accessesLinus Torvalds3-26/+63
Josh Poimboeuf reports that he got a "will-it-scale.per_process_ops 1.9% improvement" report for his patch that changed __get_user() to use pointer masking instead of the explicit speculation barrier. However, that patch doesn't actually work in the general case, because some (very bad) architecture-specific code actually depends on __get_user() also working on kernel addresses. A profile showed that the offending __get_user() was the futex code, which really should be fixed up to not use that horrid legacy case. Rewrite futex_get_value_locked() to use the modern user acccess helpers, and inline it so that the compiler not only avoids the function call for a few instructions, but can do CSE on the address masking. It also turns out the x86 futex functions have unnecessary barriers in other places, so let's fix those up too. Link: https://lore.kernel.org/all/20241115230653.hfvzyf3aqqntgp63@jpoimboe/ Reported-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-11-25Revert "HID: bpf: allow write access to quirks field in struct hid_device"Linus Torvalds5-106/+4
This reverts commit 6fd47effe92b, and the related self-test update commit e14e0eaeb040 ("selftests/hid: add test for assigning a given device to hid-generic"). It results in things like the scroll wheel on Logitech mice not working after a reboot due to the kernel being confused about the state of the high-resolution mode. Quoting Benjamin Tissoires: "The idea of 6fd47effe92b was to be able to call hid_bpf_rdesc_fixup() once per reprobe of the device. However, because the bpf filter can now change the quirk value, the call had to be moved before the driver gets bound (which was previously ensuring the unicity of the call). The net effect is that now, in the case hid-generic gets loaded first and then the specific driver gets loaded once the disk is available, the value of ->quirks is not reset, but kept to the value that was set by hid-generic (HID_QUIRK_INPUT_PER_APP). Once hid-logitech-hidpp kicks in, that quirk is now set, which creates two inputs for the single mouse: one keyboard for fancy shortcuts, and one mouse node. However, hid-logitech-hidpp expects only one input node to be attached (it stores it into hidpp->input), and when a wheel event is received, because there is some processing with high-resolution wheel events, the wheel event is injected into hidpp->input. And of course, when HID_QUIRK_INPUT_PER_APP is set, hidpp->input gets the keyboard node, which doesn't have wheel event type, and the events are ignored" Reported-and-bisected-by: Mike Galbraith <efault@gmx.de> Link: https://lore.kernel.org/all/CAHk-=wiUkQM3uheit2cNM0Y0OOY5qqspJgC8LkmOkJ2p2LDxcw@mail.gmail.com/ Acked-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-11-25rust: alloc: Fix `ArrayLayout` allocationsAsahi Lina1-1/+1
We were accidentally allocating a layout for the *square* of the object size due to a variable shadowing mishap. Fixes memory bloat and page allocation failures in drm/asahi. Reported-by: Janne Grunau <j@jannau.net> Fixes: 9e7bbfa18276 ("rust: alloc: introduce `ArrayLayout`") Signed-off-by: Asahi Lina <lina@asahilina.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Neal Gompa <neal@gompa.dev> Link: https://lore.kernel.org/r/20241123-rust-fix-arraylayout-v1-1-197e64c95bd4@asahilina.net Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-11-25docs: rust: remove spurious item in `expect` listMiguel Ojeda1-3/+1
This list started as a "when to prefer `expect`" list, but at some point during writing I changed it to a "prefer `expect` unless..." one. However, the first bullet remained, which does not make sense anymore. Thus remove it. In addition, fix nearby typo. Fixes: 04866494e936 ("Documentation: rust: discuss `#[expect(...)]` in the guidelines") Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20241117133127.473937-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-11-25rust: allow `clippy::needless_lifetimes`Miguel Ojeda1-0/+1
In beta Clippy (i.e. Rust 1.83.0), the `needless_lifetimes` lint has been extended [1] to suggest eliding `impl` lifetimes, e.g. error: the following explicit lifetimes could be elided: 'a --> rust/kernel/list.rs:647:6 | 647 | impl<'a, T: ?Sized + ListItem<ID>, const ID: u64> FusedIterator for Iter<'a, T, ID> {} | ^^ ^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_lifetimes = note: `-D clippy::needless-lifetimes` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::needless_lifetimes)]` help: elide the lifetimes | 647 - impl<'a, T: ?Sized + ListItem<ID>, const ID: u64> FusedIterator for Iter<'a, T, ID> {} 647 + impl<T: ?Sized + ListItem<ID>, const ID: u64> FusedIterator for Iter<'_, T, ID> {} A possibility would have been to clean them -- the RFC patch [2] did this, while asking if we wanted these cleanups. There is an open issue [3] in Clippy about being able to differentiate some of the new cases, e.g. those that do not involve introducing `'_`. Thus it seems others feel similarly. Thus, for the time being, we decided to `allow` the lint. Link: https://github.com/rust-lang/rust-clippy/pull/13286 [1] Link: https://lore.kernel.org/rust-for-linux/20241012231300.397010-1-ojeda@kernel.org/ [2] Link: https://github.com/rust-lang/rust-clippy/issues/13514 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20241116181538.369355-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-11-24mailbox: pcc: Check before sending MCTP PCC response ACKAdam Young2-8/+60
Type 4 PCC channels have an option to send back a response to the platform when they are done processing the request. The flag to indicate whether or not to respond is inside the message body, and thus is not available to the pcc mailbox. If the flag is not set, still set command completion bit after processing message. In order to read the flag, this patch maps the shared buffer to virtual memory. To avoid duplication of mapping the shared buffer is then made available to be used by the driver that uses the mailbox. Signed-off-by: Adam Young <admiyo@os.amperecomputing.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2024-11-24mailbox: Switch back to struct platform_driver::remove()Uwe Kleine-König11-13/+13
After commit 0edb555a65d1 ("platform: Make platform_driver::remove() return void") .remove() is (again) the right callback to implement for platform drivers. Convert all platform drivers below drivers/mailbox to use .remove(), with the eventual goal to drop struct platform_driver::remove_new(). As .remove() and .remove_new() have the same prototypes, conversion is done by just changing the structure member name in the driver initializer. Make a few indentions consistent while touching these struct initializers. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2024-11-24mailbox: imx: Modify the incorrect format specifierzhang jiao1-2/+2
Replace %i with %u in snprintf() because it is "unsigned int". Signed-off-by: zhang jiao <zhangjiao2@cmss.chinamobile.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2024-11-24mailbox: arm_mhuv2: clean up loop in get_irq_chan_comb()Dan Carpenter1-4/+4
Both the inner and outer loops in this code use the "i" iterator. The inner loop should really use a different iterator. It doesn't affect things in practice because the data comes from the device tree. The "protocol" and "windows" variables are going to be zero. That means we're always going to hit the "return &chans[channel];" statement and we're not going to want to iterate through the outer loop again. Still it's worth fixing this for future use cases. Fixes: 5a6338cce9f4 ("mailbox: arm_mhuv2: Add driver") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2024-11-24mailbox: zynqmp: setup IPI for each valid child nodeTanmay Shah1-2/+2
As per zynqmp-ipi bindings, zynqmp IPI node can have multiple child nodes. Current IPI setup function is set only for first child node. If IPI node has multiple child nodes in the device-tree, then IPI setup fails for child nodes other than first child node. In such case kernel will crash. Fix this crash by registering IPI setup function for each available child node. Signed-off-by: Tanmay Shah <tanmay.shah@amd.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2024-11-24dt-bindings: mailbox: Add thead,th1520-mailbox bindingsMichal Wilczynski2-0/+90
Add bindings for the mailbox controller. This work is based on the vendor kernel. [1] Link: https://github.com/revyos/thead-kernel.git [1] Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2024-11-24mailbox: Introduce support for T-head TH1520 Mailbox driverMichal Wilczynski4-0/+610
This driver was tested using the drm/imagination GPU driver. It was able to successfully power on the GPU, by passing a command through mailbox from E910 core to E902 that's responsible for powering up the GPU. The GPU driver was able to read the BVNC version from control registers, which confirms it was successfully powered on. [ 33.957467] powervr ffef400000.gpu: [drm] loaded firmware powervr/rogue_36.52.104.182_v1.fw [ 33.966008] powervr ffef400000.gpu: [drm] FW version v1.0 (build 6621747 OS) [ 38.978542] powervr ffef400000.gpu: [drm] *ERROR* Firmware failed to boot Though the driver still fails to boot the firmware, the mailbox driver works when used with the not-yet-upstreamed firmware AON driver. There is ongoing work to get the BXM-4-64 supported with the drm/imagination driver [1], though it's not completed yet. This work is based on the driver from the vendor kernel [2]. Link: https://gitlab.freedesktop.org/imagination/linux-firmware/-/issues/2 [1] Link: https://github.com/revyos/thead-kernel.git [2] Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2024-11-24mailbox: mtk-cmdq: fix wrong use of sizeof in cmdq_get_clocks()Yang Yingliang1-1/+1
It should be size of the struct clk_bulk_data, not data pointer pass to devm_kcalloc(). Fixes: aa1609f571ca ("mailbox: mtk-cmdq: Dynamically allocate clk_bulk_data structure") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2024-11-24dt-bindings: mailbox: qcom-ipcc: Add SM8750Krzysztof Kozlowski1-0/+1
Document compatible for Qualcomm SM8750 SoC IPCC, compatible with existing generic fallback. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2024-11-24dt-bindings: mailbox: qcom,apcs-kpss-global: correct expected clocks for ↵Krzysztof Kozlowski1-6/+7
fallbacks Commit 1e9cb7e007dc ("dt-bindings: mailbox: qcom,apcs-kpss-global: use fallbacks") and commit 34d8775a0edc ("dt-bindings: mailbox: qcom,apcs-kpss-global: use fallbacks for few variants") added fallbacks to few existing compatibles. Neither devices with these existing compatibles nor devices using fallbacks alone, have clocks, so the "if:then:" block defining this constrain should be written as "contains:". Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2024-11-24dt-bindings: mailbox: qcom-ipcc: Add SAR2130P compatibleDmitry Baryshkov1-0/+1
Document compatible for the IPCC mailbox controller on SAR2130P platform. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2024-11-24mailbox: ti-msgmgr: Allow building under COMPILE_TESTAndrew Davis1-1/+1
The TI message manager driver can be compiled without ARCH_KEYSTONE nor ARCH_K3 enabled. Allow it to be built under COMPILE_TEST. Signed-off-by: Andrew Davis <afd@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nishanth Menon <nm@ti.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2024-11-24mailbox: ti-msgmgr: Remove use of of_match_ptr() helperAndrew Davis1-1/+1
When OF support is disabled the of_device_id struct match table can be conditionally compiled out, this helper allows the assignment to also be turned into a NULL conditionally. When the of_device_id struct is not conditionally defined based on OF then the table will be unused causing a warning. The two options are to either set the table as _maybe_unused, or to just remove this helper since the table will always be defined. Do the latter here. Signed-off-by: Andrew Davis <afd@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nishanth Menon <nm@ti.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2024-11-24mailbox: qcom-cpucp: Mark the irq with IRQF_NO_SUSPEND flagSibi Sankar1-1/+1
The qcom-cpucp mailbox irq is expected to function during suspend-resume cycle particularly when the scmi cpufreq driver can query the current frequency using the get_level message after the cpus are brought up during resume. Hence mark the irq with IRQF_NO_SUSPEND flag to fix the do_xfer failures we see during resume. Err Logs: arm-scmi firmware:scmi: timed out in resp(caller:do_xfer+0x164/0x568) cpufreq: cpufreq_online: ->get() failed Reported-by: Johan Hovold <johan+linaro@kernel.org> Closes: https://lore.kernel.org/lkml/ZtgFj1y5ggipgEOS@hovoldconsulting.com/ Fixes: 0e2a9a03106c ("mailbox: Add support for QTI CPUCP mailbox controller") Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Tested-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2024-11-24mailbox: mtk-cmdq-mailbox: Switch to __pm_runtime_put_autosuspend()Sakari Ailus1-5/+5
pm_runtime_put_autosuspend() will soon be changed to include a call to pm_runtime_mark_last_busy(). This patch switches the current users to __pm_runtime_put_autosuspend() which will continue to have the functionality of old pm_runtime_put_autosuspend(). Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2024-11-24mailbox: mpfs: support new, syscon based, devicetree configurationConor Dooley2-14/+68
The two previous bindings for this hardware were incorrect, as the control/status and interrupt register regions should have been described as syscons and dealt with via regmap in the driver. Add support for accessing these registers using that method now, so that the hwmon driver can be supported without using auxdev or hacks with io_remap(). Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2024-11-24dt-bindings: mailbox: mpfs: fix reg propertiesConor Dooley1-5/+8
When the binding for this was originally written, and later modified, mistakes were made - and the precise nature of the later modification should have been a giveaway, but alas I was naive at the time. A more correct modelling of the hardware is to use two syscons and have a single reg entry for the mailbox, containing the mailbox region. The two syscons contain the general control/status registers for the mailbox and the interrupt related registers respectively. The reason for two syscons is that the same mailbox is present on the non-SoC version of the FPGA, which has no interrupt controller, and the shared part of the rtl was unchanged between devices. This is now coming to a head, because the control/status registers share a register region with the "tvs" (temperature & voltage sensors) registers and, as it turns out, people do want to monitor temperatures and voltages... Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2024-11-24MAINTAINERS: transfer i2c-aspeed maintainership from Brendan to RyanBrendan Higgins1-1/+1
Remove Brendan Higgins <brendanhiggins@google.com> from i2c-aspeed entry and replace with Ryan Chen <ryan_chen@aspeedtech.com>. Signed-off-by: Brendan Higgins <brendanhiggins@google.com> Acked-by: Ryan Chen <ryan_chen@aspeedtech.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2024-11-24i2c: designware: determine HS tHIGH and tLOW based on HW parametersMichael Wu3-2/+32
In commit 35eba185fd1a ("i2c: designware: Calculate SCL timing parameter for High Speed Mode") the SCL high period count and low period count for high speed mode are calculated based on fixed tHIGH = 160 and tLOW = 120. However, the set of two fixed values is only applicable to the combination of hardware parameters IC_CAP_LOADING is 400 and IC_CLK_FREQ_OPTIMIZATION is true. Outside of this combination, the SCL frequency may not reach 3.4 MHz because the fixed tHIGH and tLOW are not small enough. If IC_CAP_LOADING is 400, it means the bus capacitance is 400pF; Otherwise, 100 pF. If IC_CLK_FREQ_OPTIMIZATION is true, it means that the hardware reduces its internal clock frequency by reducing the internal latency required to generate the high period and low period of the SCL line. Section 3.15.4.5 in DesignWare DW_apb_i2b Databook v2.03 says that when IC_CLK_FREQ_OPTIMIZATION = 0, MIN_SCL_HIGHtime = 60 ns for 3.4 Mbps, bus loading = 100pF = 120 ns for 3.4 Mbps, bus loading = 400pF MIN_SCL_LOWtime = 160 ns for 3.4 Mbps, bus loading = 100pF = 320 ns for 3.4 Mbps, bus loading = 400pF and section 3.15.4.6 says that when IC_CLK_FREQ_OPTIMIZATION = 1, MIN_SCL_HIGHtime = 60 ns for 3.4 Mbps, bus loading = 100pF = 160 ns for 3.4 Mbps, bus loading = 400pF MIN_SCL_LOWtime = 120 ns for 3.4 Mbps, bus loading = 100pF = 320 ns for 3.4 Mbps, bus loading = 400pF In order to calculate more accurate SCL high period count and low period count for high speed mode, two hardware parameters IC_CAP_LOADING and IC_CLK_FREQ_OPTIMIZATION must be considered together. Since there're no registers controlliing these these two hardware parameters, users can declare them in the device tree so that the driver can obtain them. Signed-off-by: Michael Wu <michael.wu@kneron.us> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2024-11-24dt-bindings: i2c: snps,designware-i2c: declare bus capacitance and clk freq ↵Michael Wu1-0/+18
optimized Since there are no registers controlling the hardware parameters IC_CAP_LOADING and IC_CLK_FREQ_OPTIMIZATION, their values can only be declared in the device tree. snps,bus-capacitance-pf indicates the bus capacitance in picofarads (pF). It affects the high and low pulse width of SCL line in high speed mode. The legal values for this property are 100 and 400 only, and default value is 100. This property corresponds to IC_CAP_LOADING. snps,clk-freq-optimized indicates whether the hardware reduce its internal clock frequency by reducing the internal latency required to generate the high period and low period of SCL line. This property corresponds to IC_CLK_FREQ_OPTIMIZATION. The driver can calculate the high period count and low period count of SCL line for high speed mode based on these two properties. Signed-off-by: Michael Wu <michael.wu@kneron.us> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2024-11-24i2c: nomadik: support >=1MHz speed modesThéo Lebrun1-24/+16
- BRCR value must go into the BRCR1 field when in high-speed mode. It goes into BRCR2 otherwise. - Remove fallback to standard mode if priv->sm > I2C_FREQ_MODE_FAST. - Set SM properly in probe; previously it only checked STANDARD versus FAST. Now we set STANDARD, FAST, FAST_PLUS or HIGH_SPEED. - Remove all comment sections saying we only support low-speeds. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2024-11-24i2c: nomadik: fix BRCR computationThéo Lebrun1-1/+5
Current BRCR computation is: brcr = floor(i2cclk / (clkfreq * div)) With brcr: "baud rate counter", an internal clock divider, and i2cclk: input clock rate (24MHz, 38.4MHz or 48MHz), and clkfreq: desired bus rate, and div: speed-mode dependent divider (2 for standard, 3 otherwise). Assume i2cclk=48MHz, clkfreq=3.4MHz, div=3, then brcr = floor(48MHz / (3.4MHz * 3)) = 4 and resulting bus rate = 48MHz / (4 * 3) = 4MHz Assume i2cclk=38.4MHz, clkfreq=1.0MHz, div=3, then brcr = floor(38.4MHz / (1.0MHz * 3)) = 12 and resulting bus rate = 38.4MHz / (12 * 3) = 1066kHz The current computation means we always pick the smallest divider that gives a bus rate above target. We should instead pick the largest divider that gives a bus rate below target, using: brcr = floor(i2cclk / (clkfreq * div)) + 1 If we redo the above examples: Assume i2cclk=48MHz, clkfreq=3.4MHz, div=3, then brcr = floor(48MHz / (3.4MHz * 3)) + 1 = 5 and resulting bus rate = 48MHz / (5 * 3) = 3.2MHz Assume i2cclk=38.4MHz, clkfreq=1.0MHz, div=3, then brcr = floor(38.4MHz / (1.0MHz * 3)) + 1 = 13 and resulting bus rate = 38.4MHz / (13 * 3) = 985kHz In kernel C code, floor(x) is DIV_ROUND_DOWN() and, floor(x)+1 is DIV_ROUND_UP(). This is much less of an issue with slower bus rates (ie those currently supported), because the gap from one divider to the next is much smaller. It however keeps us from always using bus rates superior to the target. This fix is required for later on supporting faster bus rates: I2C_FREQ_MODE_FAST_PLUS (1MHz) and I2C_FREQ_MODE_HIGH_SPEED (3.4MHz). Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2024-11-24i2c: nomadik: support Mobileye EyeQ6H I2C controllerThéo Lebrun1-2/+6
Add EyeQ6H support to the nmk-i2c AMBA driver. It shares the same quirk as EyeQ5: the memory bus only supports 32-bit accesses. Avoid writeb() and readb() by reusing the same `priv->has_32b_bus` flag. It does NOT need to write speed-mode specific value into a register; therefore it does not depend on the mobileye,olb DT property. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2024-11-24i2c: nomadik: switch from of_device_is_compatible() to of_match_device()Théo Lebrun1-8/+27
Compatible-specific behavior is implemented using a if-condition on the return value from of_device_is_compatible(), from probe. It does not scale well when compatible number increases. Switch to using a match table and a call to of_match_device(). We DO NOT attach a .of_match_table field to our amba driver, as we do not use the table to match our driver to devices. Sort probe variable declarations in reverse christmas tree to try and introduce some logic into the ordering. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2024-11-24dt-bindings: i2c: nomadik: support 400kHz < clock-frequency <= 3.4MHzThéo Lebrun1-1/+1
Hardware is not limited to 400kHz, its documentation does mention how to configure it for high-speed (a specific Speed-Mode enum value and a different bus rate clock divider register to be used). Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2024-11-24dt-bindings: i2c: nomadik: add mobileye,eyeq6h-i2c bindingsThéo Lebrun1-5/+6
After EyeQ5, it is time for Mobileye EyeQ6H to reuse the Nomadik I2C controller. Add a specific compatible because its HW integration is slightly different from EyeQ5. Do NOT add an example as it looks like EyeQ5 from a DT standpoint (without the mobileye,olb property). Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2024-11-24dt-bindings: i2c: mv64xxx: Add Allwinner A523 compatible stringAndre Przywara1-0/+1
The I2C controller IP used in the Allwinner A523/T527 SoCs is compatible with the ones used in the other recent Allwinner SoCs. Add the A523 specific compatible string to the list of existing names falling back to the allwinner,sun8i-v536-i2c string. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2024-11-24i2c: designware: Add ACPI HID for DWAPB I2C controller on FUJITSU-MONAKAYoshihiro Furudera1-0/+1
Enable DWAPB I2C controller support on FUJITSU-MONAKA. This will be used in the FUJITSU-MONAKA server scheduled for shipment in 2027. The DSDT information obtained when verified using an in-house simulator is presented below. Device (SMB0) { Name (_HID, "FUJI200B") // _HID: Hardware ID Name (_UID, Zero) // _UID: Unique ID ... Name (_CRS, ResourceTemplate () { Memory32Fixed (ReadWrite, 0x2A4B0000, // Address Base 0x00010000, // Address Length ) Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, ) { 0x00000159, } }) ... } The expression SMB0 is used to indicate SMBus HC#0, a string of up to four characters. Created the SMB0 object according to the following specifications: ACPI Specification 13.2. Accessing the SMBus from ASL Code https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/13_ACPI_System_Mgmt_Bus_Interface_Spec/accessing-the-smbus-from-asl-code.html IPMI Specification Example 4: SSIF Interface(P574) https://www.intel.co.jp/content/www/jp/ja/products/docs/servers/ipmi/ipmi-second-gen-interface-spec-v2-rev1-1.html Signed-off-by: Yoshihiro Furudera <fj5100bi@fujitsu.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2024-11-24i2c: qup: use generic device property accessorsBartosz Golaszewski1-2/+2
There's no reason for this driver to use OF-specific property helpers. Drop the last one in favor of the generic variant and no longer include of.h. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2024-11-23f2fs: fix to drop all discards after creating snapshot on lvm deviceChao Yu2-7/+21
Piergiorgio reported a bug in bugzilla as below: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 969 at fs/f2fs/segment.c:1330 RIP: 0010:__submit_discard_cmd+0x27d/0x400 [f2fs] Call Trace: __issue_discard_cmd+0x1ca/0x350 [f2fs] issue_discard_thread+0x191/0x480 [f2fs] kthread+0xcf/0x100 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30 w/ below testcase, it can reproduce this bug quickly: - pvcreate /dev/vdb - vgcreate myvg1 /dev/vdb - lvcreate -L 1024m -n mylv1 myvg1 - mount /dev/myvg1/mylv1 /mnt/f2fs - dd if=/dev/zero of=/mnt/f2fs/file bs=1M count=20 - sync - rm /mnt/f2fs/file - sync - lvcreate -L 1024m -s -n mylv1-snapshot /dev/myvg1/mylv1 - umount /mnt/f2fs The root cause is: it will update discard_max_bytes of mounted lvm device to zero after creating snapshot on this lvm device, then, __submit_discard_cmd() will pass parameter @nr_sects w/ zero value to __blkdev_issue_discard(), it returns a NULL bio pointer, result in panic. This patch changes as below for fixing: 1. Let's drop all remained discards in f2fs_unfreeze() if snapshot of lvm device is created. 2. Checking discard_max_bytes before submitting discard during __submit_discard_cmd(). Cc: stable@vger.kernel.org Fixes: 35ec7d574884 ("f2fs: split discard command in prior to block layer") Reported-by: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219484 Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2024-11-23f2fs: add a sysfs node to limit max read extent count per-inodeChao Yu4-1/+24
Quoted: "at this time, there are still 1086911 extent nodes in this zombie extent tree that need to be cleaned up. crash_arm64_sprd_v8.0.3++> extent_tree.node_cnt ffffff80896cc500 node_cnt = { counter = 1086911 }, " As reported by Xiuhong, there will be a huge number of extent nodes in extent tree, it may potentially cause: - slab memory fragments - extreme long time shrink on extent tree - low mapping efficiency Let's add a sysfs node to limit max read extent count for each inode, by default, value of this threshold is 10240, it can be updated according to user's requirement. Reported-by: Xiuhong Wang <xiuhong.wang@unisoc.com> Closes: https://lore.kernel.org/linux-f2fs-devel/20241112110627.1314632-1-xiuhong.wang@unisoc.com/ Signed-off-by: Xiuhong Wang <xiuhong.wang@unisoc.com> Signed-off-by: Zhiguo Niu <zhiguo.niu@unisoc.com> Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2024-11-22docs: Add debugging guide for the media subsystemSebastian Fricke3-0/+198
Provide a guide for developers on how to debug code with a focus on the media subsystem. This document aims to provide a rough overview over the possibilities and a rational to help choosing the right tool for the given circumstances. Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20241028-media_docs_improve_v3-v3-2-edf5c5b3746f@collabora.com
2024-11-22docs: Add debugging section to processSebastian Fricke4-3/+573
This idea was formed after noticing that new developers experience certain difficulty to navigate within the multitude of different debugging options in the Kernel and while there often is good documentation for the tools, the developer has to know first that they exist and where to find them. Add a general debugging section to the Kernel documentation, as an easily locatable entry point to other documentation and as a general guideline for the topic. Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20241028-media_docs_improve_v3-v3-1-edf5c5b3746f@collabora.com
2024-11-22docs/licensing: Clarify wording about "GPL" and "Proprietary"Uwe Kleine-König2-9/+11
There are currently some doubts about out-of-tree kernel modules licensed under GPLv3 and if they are supposed to be able to use symbols exported using EXPORT_SYMBOL_GPL. Clarify that "Proprietary" means anything non-GPL2 even though the license might be an open source license. Also disambiguate "GPL compatible" to "GPLv2 compatible". Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20241115103842.585207-2-ukleinek@kernel.org
2024-11-22docs: core-api/gfp_mask-from-fs-io: indicate that vmalloc supports ↵Pavel Tikhomirov1-9/+11
GFP_NOFS/GFP_NOIO After the commit 451769ebb7e79 ("mm/vmalloc: alloc GFP_NO{FS,IO} for vmalloc") in v5.17 it is now safe to use GFP_NOFS/GFP_NOIO flags in [k]vmalloc, let's reflect it in documentation. Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com> Acked-by: Michal Hocko <mhocko@suse.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20241119093922.567138-1-ptikhomirov@virtuozzo.com
2024-11-22Documentation: kernel-doc: enumerate identifier *type*sRandy Dunlap1-0/+1
Explain that a kernel-doc :identifiers: line can refer to a struct, union, enum, or typedef as well as functions. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20241119203201.110953-1-rdunlap@infradead.org
2024-11-22Documentation: pwrseq: Fix trivial misspellingsJavier Carrasco1-4/+4
Use proper spelling for 'discrete'. When at it, capitalize 'Linux', which is common practice in the documentation. Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20241120-pwrseq-doc-trivial-fixes-v1-1-19a70f4dd156@gmail.com
2024-11-22Documentation: filesystems: update filename extensionsRandy Dunlap6-6/+6
Update references to most txt files to rst files. Update one reference to an md file to a rst file. Update one file path to its current location. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: linux-doc@vger.kernel.org Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Christian Brauner <brauner@kernel.org> Cc: Jan Kara <jack@suse.cz> Cc: linux-fsdevel@vger.kernel.org Cc: Ian Kent <raven@themaw.net> Cc: autofs@vger.kernel.org Cc: Alexander Aring <aahringo@redhat.com> Cc: David Teigland <teigland@redhat.com> Cc: gfs2@lists.linux.dev Cc: Eric Biggers <ebiggers@kernel.org> Cc: Theodore Y. Ts'o <tytso@mit.edu> Cc: fsverity@lists.linux.dev Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Joseph Qi <joseph.qi@linux.alibaba.com> Cc: ocfs2-devel@lists.linux.dev Reviewed-by: Christian Brauner (Microsoft) <brauner@kernel.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20241120055246.158368-1-rdunlap@infradead.org
2024-11-21tpm: atmel: Drop PPC64 specific MMIO setupRob Herring (Arm)3-144/+61
The PPC64 specific MMIO setup open codes DT address functions rather than using standard address parsing functions. The open-coded version fails to handle any address translation and is not endian safe. I haven't found any evidence of what platform used this. The only thing that turned up was a PPC405 platform, but that is 32-bit and PPC405 support is being removed as well. CONFIG_TCG_ATMEL is not enabled for any powerpc config and never was. The support was added in 2005 and hasn't been touched since. Rather than try to modernize and fix this code, just remove it. [jarkko: fixed couple of style issues reported by checkpatch.pl --strict and put offset into parentheses in the macro declarations.] Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Acked-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2024-11-21char: tpm: cr50: Add new device/vendor ID 0x50666666Jett Rink1-4/+28
Accept another DID:VID for the next generation Google TPM. This TPM has the same Ti50 firmware and fulfills the same interface. Suggested-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2024-11-21char: tpm: cr50: Move i2c locking to request/relinquish locality opsJan Dabros1-9/+13
Move i2c locking primitives to request_locality and relinquish_locality callbacks, what effectively blocks TPM bus for the whole duration of logical TPM operation. With this in place, cr50-equipped TPM may be shared with external CPUs - assuming that underneath i2c controller driver is aware of this setup (see i2c-designware-amdpsp as an example). Signed-off-by: Jan Dabros <jsd@semihalf.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2024-11-21char: tpm: cr50: Use generic request/relinquish locality opsJan Dabros1-40/+54
Instead of using static functions tpm_cr50_request_locality and tpm_cr50_release_locality register callbacks from tpm class chip->ops created for this purpose. Signed-off-by: Jan Dabros <jsd@semihalf.com> Signed-off-by: Grzegorz Bernacki <bernacki@chromium.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2024-11-21tpm: ibmvtpm: Set TPM_OPS_AUTO_STARTUP flag on driverStefan Berger2-15/+1
Set the TPM_OPS_AUTO_STARTUP on the driver so that the ibmvtpm driver now uses tpm2_auto_startup and tpm1_auto_startup like many other drivers do. Remove tpm_get_timeouts, tpm2_get_cc_attrs_tbl, and tpm2_sessions_init calls from it since these will all be called in tpm2_auto_startup and tpm1_auto_startup. The exporting of the tpm2_session_init symbol was only necessary while the ibmvtpm driver was calling this function. Since this is not the case anymore, remove this symbol from being exported. What is new for the ibmvtpm driver is that now tpm2_do_selftest and tpm1_do_selftest will be called that send commands to the TPM to perform or continue its selftest. However, the firmware should already have sent these commands so that the TPM will not do much work at this time. Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2024-11-21smb: prevent use-after-free due to open_cached_dir error pathsPaul Aurich1-41/+29
If open_cached_dir() encounters an error parsing the lease from the server, the error handling may race with receiving a lease break, resulting in open_cached_dir() freeing the cfid while the queued work is pending. Update open_cached_dir() to drop refs rather than directly freeing the cfid. Have cached_dir_lease_break(), cfids_laundromat_worker(), and invalidate_all_cached_dirs() clear has_lease immediately while still holding cfids->cfid_list_lock, and then use this to also simplify the reference counting in cfids_laundromat_worker() and invalidate_all_cached_dirs(). Fixes this KASAN splat (which manually injects an error and lease break in open_cached_dir()): ================================================================== BUG: KASAN: slab-use-after-free in smb2_cached_lease_break+0x27/0xb0 Read of size 8 at addr ffff88811cc24c10 by task kworker/3:1/65 CPU: 3 UID: 0 PID: 65 Comm: kworker/3:1 Not tainted 6.12.0-rc6-g255cf264e6e5-dirty #87 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Workqueue: cifsiod smb2_cached_lease_break Call Trace: <TASK> dump_stack_lvl+0x77/0xb0 print_report+0xce/0x660 kasan_report+0xd3/0x110 smb2_cached_lease_break+0x27/0xb0 process_one_work+0x50a/0xc50 worker_thread+0x2ba/0x530 kthread+0x17c/0x1c0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 2464: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 open_cached_dir+0xa7d/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 2464: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x51/0x70 kfree+0x174/0x520 open_cached_dir+0x97f/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Last potentially related work creation: kasan_save_stack+0x33/0x60 __kasan_record_aux_stack+0xad/0xc0 insert_work+0x32/0x100 __queue_work+0x5c9/0x870 queue_work_on+0x82/0x90 open_cached_dir+0x1369/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The buggy address belongs to the object at ffff88811cc24c00 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 16 bytes inside of freed 1024-byte region [ffff88811cc24c00, ffff88811cc25000) Cc: stable@vger.kernel.org Signed-off-by: Paul Aurich <paul@darkrain42.org> Signed-off-by: Steve French <stfrench@microsoft.com>