| Age | Commit message (Collapse) | Author |
|---|
|
There are two flags used to synchronize allocation and scanning with
swapoff: SWP_WRITEOK and SWP_SCANNING.
SWP_WRITEOK: Swapoff will first unset this flag, at this point any further
swap allocation or scanning on this device should just abort so no more
new entries will be referencing this device. Swapoff will then unuse all
existing swap entries.
SWP_SCANNING: This flag is set when device is being scanned. Swapoff will
wait for all scanner to stop before the final release of the swap device
structures to avoid UAF. Note this flag is the highest used bit of
si->flags so it could be added up arithmetically, if there are multiple
scanner.
commit 5f843a9a3a1e ("mm: swap: separate SSD allocation from
scan_swap_map_slots()") ignored SWP_SCANNING and SWP_WRITEOK flags while
separating cluster allocation path from the old allocation path. Add the
flags back to fix swapoff race. The race is hard to trigger as si->lock
prevents most parallel operations, but si->lock could be dropped for
reclaim or discard. This issue is found during code review.
This commit fixes this problem. For SWP_SCANNING, Just like before, set
the flag before scan and remove it afterwards.
For SWP_WRITEOK, there are several places where si->lock could be dropped,
it will be error-prone and make the code hard to follow if we try to cover
these places one by one. So just do one check before the real allocation,
which is also very similar like before. With new cluster allocator it may
waste a bit of time iterating the clusters but won't take long, and
swapoff is not performance sensitive.
Link: https://lkml.kernel.org/r/20241112083414.78174-1-ryncsn@gmail.com
Fixes: 5f843a9a3a1e ("mm: swap: separate SSD allocation from scan_swap_map_slots()")
Reported-by: "Huang, Ying" <ying.huang@intel.com>
Closes: https://lore.kernel.org/linux-mm/87a5es3f1f.fsf@yhuang6-desk2.ccr.corp.intel.com/
Signed-off-by: Kairui Song <kasong@tencent.com>
Cc: Barry Song <v-songbaohua@oppo.com>
Cc: Chris Li <chrisl@kernel.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: Kalesh Singh <kaleshsingh@google.com>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
Previous setup was:
- pll-west clock registered from driver at of_clk_init();
- Both OCC and UART clocks registered from DT using fixed-factor-clock
compatible.
Now that drivers/clk/clk-eyeq.c supports registering fixed factors, use
that capability to register west-per-occ and west-per-uart (giving them
proper names at the same time).
Also switch from hard-coded index 0 for pll-west to using the
EQ6HC_WEST_PLL_PER constant by exposed dt-bindings headers.
All get exposed at of_clk_init() because they get used by the AMBA PL011
serial ports. Those are instantiated before platform bus infrastructure.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://lore.kernel.org/r/20241106-mbly-clk-v2-8-84cfefb3f485@bootlin.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Previous setup was:
- pll-cpu clock registered from driver at of_clk_init();
- occ-cpu clock registered from DT using fixed-factor-clock compatible.
Now that drivers/clk/clk-eyeq.c supports registering fixed factors, use
that capability to register occ-cpu.
Also switch from hard-coded index 0 for pll-cpu to using the
EQ6HC_CENTRAL_PLL_CPU constant by exposed dt-bindings headers.
occ-cpu is exposed at of_clk_init() because it gets used by both the DT
CPU nodes and the GIC timer.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://lore.kernel.org/r/20241106-mbly-clk-v2-7-84cfefb3f485@bootlin.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Expose additional clocks on EyeQ5. Some indexes come from dt-bindings
headers, others are private to the driver.
Few clocks are early (of_clk_init() stage: core clocks and UART clock),
others can wait until platform device probe. The source for this list
is downstream Mobileye kernel and some internal documentation.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://lore.kernel.org/r/20241106-mbly-clk-v2-6-84cfefb3f485@bootlin.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Driver can currently host two types of clocks:
- PLLs derived directly from the main crystal (taken using a fwhandle).
- Divider clocks derived from those PLLs.
PLLs can be instantiated from of_clk_init() or platform device probe,
using two separate clock providers. Divider clocks are all instantiated
at platform device probe.
Add a third type of clocks: fixed factors. Those can be instantiated at
both stages. They can be parented to any clock from the driver. Early
match data and match data store the list of fixed factor clocks.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://lore.kernel.org/r/20241106-mbly-clk-v2-5-84cfefb3f485@bootlin.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
We used to let compatibles with a single clock exposed to not have
a cell. Switch away from that and enforce a cell in all cases.
This is done at the same time as some compatibles
(mobileye,eyeq6h-{central,west}-olb) go from one to more clocks
exposed. Let's do the same switch and avoid future devicetree
work if/when others follow.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://lore.kernel.org/r/20241106-mbly-clk-v2-4-84cfefb3f485@bootlin.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Add non-devres version of clk_hw_register_fixed_factor(), with parent
targeted using its index.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://lore.kernel.org/r/20241106-mbly-clk-v2-3-84cfefb3f485@bootlin.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Add #defines for Mobileye clock controller:
- EyeQ5 core 0 thru 3 clocks. Internally:
EQ5C_PLL_CPU: already exposed
└── EQ5C_CPU_OCC: unexposed, no reason to do so
├── EQ5C_CPU_CORE0: new!
├── EQ5C_CPU_CORE1: new!
├── EQ5C_CPU_CORE2: new!
└── EQ5C_CPU_CORE3: new!
- EyeQ5 peripheral clocks. Internally:
EQ5C_PLL_PER: already exposed
├── EQ5C_PER_OCC: new!
│ ├── EQ5C_PER_SPI: new!
│ ├── EQ5C_PER_I2C: new!
│ ├── EQ5C_PER_GPIO: new!
│ └── EQ5C_PER_UART: new!
├── EQ5C_PER_EMMC: new!
└── EQ5C_PER_OCC_PCI: new!
- EyeQ6H central OLB. Internally:
EQ6HC_CENTRAL_PLL_CPU: new!
└── EQ6HC_CENTRAL_CPU_OCC: new!
- EyeQ6H west OLB. Internally:
EQ6HC_WEST_PLL_PER: new!
└── EQ6HC_WEST_PER_OCC: new!
└── EQ6HC_WEST_PER_UART: new!
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://lore.kernel.org/r/20241106-mbly-clk-v2-2-84cfefb3f485@bootlin.com
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Some compatibles expose a single clock. For those, we used to let them
using `#clock-cells = <0>` (ie <&olb> reference rather than <&olb 0>).
Switch away from that: enforce a cell for all compatibles. This is more
straight forward, and avoids devicetree changes whenever a compatible
goes from exposing a single clock to multiple ones. Also, dt-bindings
get simpler.
*This is an ABI break*. Change it while EyeQ5 platform support is at its
infancy, without any user. More clocks might hide in each OLB as some
registers are still unknown.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://lore.kernel.org/r/20241106-mbly-clk-v2-1-84cfefb3f485@bootlin.com
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
In order to access the registers of the HW, we need to make sure that
the AXI bus clock is enabled. Hence let's increase the number of clocks
by one.
In order to keep backward compatibility and make sure old DTs still work
we check if clock-names is available or not. If it is, then we can
disambiguate between really having the AXI clock or a parent clock and
so we can enable the bus clock. If not, we fallback to what was done
before and don't explicitly enable the AXI bus clock.
Note that if clock-names is given, the axi clock must be the last one in
the phandle array (also enforced in the DT bindings) so that we can reuse
as much code as possible.
Fixes: 0e646c52cf0e ("clk: Add axi-clkgen driver")
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20241029-axi-clkgen-fix-axiclk-v2-2-bc5e0733ad76@analog.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
In order to access the registers of the HW, we need to make sure that
the AXI bus clock is enabled. Hence let's increase the number of clocks
by one and add clock-names to differentiate between parent clocks and
the bus clock.
Fixes: 0e646c52cf0e ("clk: Add axi-clkgen driver")
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20241029-axi-clkgen-fix-axiclk-v2-1-bc5e0733ad76@analog.com
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into clk-bindings
Pull a YAML conversion of the rk3328 clock controller binding from Heiko
Stuebner.
* tag 'v6.13-rockchip-clk1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
dt-bindings: clock: convert rockchip,rk3328-cru.txt to YAML
|
|
Add driver for the MPMU controller block on Marvell's PXA1908 SoC. The
driver is incomplete, currently only supporting the fixed PLL1; dynamic
PLLs 2-4 and CPU/DDR/AXI clock support is missing.
Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr>
Link: https://lore.kernel.org/r/20241104-pxa1908-lkml-v13-8-e050609b8d6c@skole.hr
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Add driver for the APMU controller block found on Marvell's PXA1908 SoC.
This driver is incomplete, lacking support for (at least) GPU, VPU, DSI
and CCIC (camera related) clocks.
Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr>
Link: https://lore.kernel.org/r/20241104-pxa1908-lkml-v13-7-e050609b8d6c@skole.hr
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Add driver for the APBCP controller block found on Marvell's PXA1908
SoC.
Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr>
Link: https://lore.kernel.org/r/20241104-pxa1908-lkml-v13-6-e050609b8d6c@skole.hr
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Add driver for the APBC controller block found on Marvell's PXA1908 SoC.
Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr>
Link: https://lore.kernel.org/r/20241104-pxa1908-lkml-v13-5-e050609b8d6c@skole.hr
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Add dt bindings and documentation for the Marvell PXA1908 clock
controller.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr>
Link: https://lore.kernel.org/r/20241104-pxa1908-lkml-v13-4-e050609b8d6c@skole.hr
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
The struct mmp_clk_factor_tbl repeats the generic struct u32_fract.
Kill the custom one and use the generic one instead.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Duje Mihanović <duje.mihanovic@skole.hr>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr>
Link: https://lore.kernel.org/r/20241104-pxa1908-lkml-v13-1-e050609b8d6c@skole.hr
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Map all clock-controller memory region in a single block.
This patch does not introduce any backward incompatibility since the dts
for EN7581 SoC is not upstream yet.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://lore.kernel.org/r/20241112-clk-en7581-syscon-v2-7-8ada5e394ae4@kernel.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Move en7581_reset_register routine in en7581_clk_hw_init() since reset
feature is supported just by EN7581 SoC.
Get rid of reset struct in en_clk_soc_data data struct.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://lore.kernel.org/r/20241112-clk-en7581-syscon-v2-6-8ada5e394ae4@kernel.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Introduce en7581_base_clks array in order to define per-SoC fixed-rate
clock parameters and fix wrong parameters for emi, npu and crypto EN7581
clocks
Fixes: 66bc47326ce2 ("clk: en7523: Add EN7581 support")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://lore.kernel.org/r/20241112-clk-en7581-syscon-v2-5-8ada5e394ae4@kernel.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Introduce chip_scu regmap pointer since EN7581 SoC will access chip-scu
memory area via a syscon node. Remove first memory region mapping
for EN7581 SoC. This patch does not introduce any backward incompatibility
since the dts for EN7581 SoC is not upstream yet.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://lore.kernel.org/r/20241112-clk-en7581-syscon-v2-4-8ada5e394ae4@kernel.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Move en7523_register_clocks routine in hw_init callback.
Introduce en7523_clk_hw_init callback for EN7523 SoC.
This is a preliminary patch to differentiate IO mapped region between
EN7523 and EN7581 SoCs in order to access chip-scu IO region
<0x1fa20000 0x384> on EN7581 SoC as syscon device since it contains
miscellaneous registers needed by multiple devices (clock, pinctrl ..).
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://lore.kernel.org/r/20241112-clk-en7581-syscon-v2-3-8ada5e394ae4@kernel.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
REG_PCIE*_MEM and REG_PCIE*_MEM_MASK regs (PBUS_CSR memory region) are not
part of the scu block on the EN7581 SoC and they are used to select the
PCIE ports on the PBUS, so remove this configuration from the clock driver
and set these registers in the PCIE host driver instead.
This patch does not introduce any backward incompatibility since the dts
for EN7581 SoC is not upstream yet.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://lore.kernel.org/r/20241112-clk-en7581-syscon-v2-2-8ada5e394ae4@kernel.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
clk-en7523 driver for EN7581 SoC is mapping all the scu memory region
while it is configuring the chip-scu one via a syscon. Update the reg
mapping definition for this device. This patch does not introduce any
backward incompatibility since the dts for EN7581 SoC is not upstream
yet.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://lore.kernel.org/r/20241112-clk-en7581-syscon-v2-1-8ada5e394ae4@kernel.org
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Add drivers for IMGSYS, MFGCFG, VDECSYS and VENCSYS clocks and resets
on MT6735.
Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com>
Link: https://lore.kernel.org/r/20241106111402.200940-3-y.oudjana@protonmail.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
controllers
Add device tree bindings for syscon clock and reset controllers (IMGSYS,
MFGCFG, VDECSYS and VENCSYS).
Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20241106111402.200940-2-y.oudjana@protonmail.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
clk_mt6735_apmixed_probe()
If an error occurs after a successful mtk_alloc_clk_data(),
mtk_free_clk_data() should be called, as already done in the .remove()
function.
Switch to mtk_devm_alloc_clk_data() in order to fix the memory leak in the
probe function, and simplify the remove function.
Fixes: 43c04ed79189 ("clk: mediatek: Add drivers for MediaTek MT6735 main clock and reset drivers")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/89ad840e7a484eaf4727470824acfe0fdc60fcef.1729871146.git.christophe.jaillet@wanadoo.fr
Tested-by: Yassine Oudjana <y.oudjana@protonmail.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Original architecture clock code from where this driver was derived did not
include nothing related to mmc clocks. OpenWRT people started to use mtk-sd
upstream driver recently and they were forced to use a dts 'fixed-clock'
node with 48 MHz clock:
- https://github.com/openwrt/openwrt/pull/15896
The proper thing to do to avoid that is to add the mmc related clocks to the
driver to avoid a dts with fixed clocks nodes. The minimal documentation in
the mt7620 programming guide says that there is a BBP_PLL clock of 480 MHz
derived from the 40 MHz XTAL and from there a clock divider by ten produces
the desired SDHC clock of 48 MHz for the mmc. Hence add a fixed clock 'bbppll'
and factor clock 'sdhc' ten divider child to properly set the 'mmc' peripheral
clock with the desired 48 Mhz rate.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20240910044024.120009-4-sergio.paracuellos@gmail.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Base clocks are the first in being probed and are real dependencies of the
rest of fixed, factor and peripheral clocks. For old ralink SoCs RT2880,
RT305x and RT3883 'xtal' must be defined first since in any other case,
when fixed clocks are probed they are delayed until 'xtal' is probed so the
following warning appears:
WARNING: CPU: 0 PID: 0 at drivers/clk/ralink/clk-mtmips.c:499 rt3883_bus_recalc_rate+0x98/0x138
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.43 #0
Stack : 805e58d0 00000000 00000004 8004f950 00000000 00000004 00000000 00000000
80669c54 80830000 80700000 805ae570 80670068 00000001 80669bf8 00000000
00000000 00000000 805ae570 80669b38 00000020 804db7dc 00000000 00000000
203a6d6d 80669b78 80669e48 70617773 00000000 805ae570 00000000 00000009
00000000 00000001 00000004 00000001 00000000 00000000 83fe43b0 00000000
...
Call Trace:
[<800065d0>] show_stack+0x64/0xf4
[<804bca14>] dump_stack_lvl+0x38/0x60
[<800218ac>] __warn+0x94/0xe4
[<8002195c>] warn_slowpath_fmt+0x60/0x94
[<80259ff8>] rt3883_bus_recalc_rate+0x98/0x138
[<80254530>] __clk_register+0x568/0x688
[<80254838>] of_clk_hw_register+0x18/0x2c
[<8070b910>] rt2880_clk_of_clk_init_driver+0x18c/0x594
[<8070b628>] of_clk_init+0x1c0/0x23c
[<806fc448>] plat_time_init+0x58/0x18c
[<806fdaf0>] time_init+0x10/0x6c
[<806f9bc4>] start_kernel+0x458/0x67c
---[ end trace 0000000000000000 ]---
When this driver was mainlined we could not find any active users of old
ralink SoCs so we cannot perform any real tests for them. Now, one user
of a Belkin f9k1109 version 1 device which uses RT3883 SoC appeared and
reported some issues in openWRT:
- https://github.com/openwrt/openwrt/issues/16054
Thus, define a 'rt2880_xtal_recalc_rate()' just returning the expected
frequency 40Mhz and use it along the old ralink SoCs to have a correct
boot trace with no warnings and a working clock plan from the beggining.
Fixes: 6f3b15586eef ("clk: ralink: add clock and reset driver for MTMIPS SoCs")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20240910044024.120009-3-sergio.paracuellos@gmail.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Clock plan for Ralink SoC RT3883 needs an extra 'periph' clock to properly
set some peripherals that has this clock as their parent. When this driver
was mainlined we could not find any active users of this SoC so we cannot
perform any real tests for it. Now, one user of a Belkin f9k1109 version 1
device which uses this SoC appear and reported some issues in openWRT:
- https://github.com/openwrt/openwrt/issues/16054
The peripherals that are wrong are 'uart', 'i2c', 'i2s' and 'uartlite' which
has a not defined 'periph' clock as parent. Hence, introduce it to have a
properly working clock plan for this SoC.
Fixes: 6f3b15586eef ("clk: ralink: add clock and reset driver for MTMIPS SoCs")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20240910044024.120009-2-sergio.paracuellos@gmail.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes
amd-drm-fixes-6.12-2024-11-14:
amdgpu:
- PSR fix
- Panel replay fixes
- DML fix
- vblank power fix
- Fix video caps
- SMU 14.0 fix
- GPUVM fix
- MES 12 fix
- APU carve out fix
- DC vbios fix
- NBIO fix
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241114143401.448210-1-alexander.deucher@amd.com
|
|
This adds the initial implementation of MGMT_OP_HCI_CMD_SYNC as
documented in mgmt-api (BlueZ tree):
Send HCI command and wait for event Command
===========================================
Command Code: 0x005B
Controller Index: <controller id>
Command Parameters: Opcode (2 Octets)
Event (1 Octet)
Timeout (1 Octet)
Parameter Length (2 Octets)
Parameter (variable)
Return Parameters: Response (1-variable Octets)
This command may be used to send a HCI command and wait for an
(optional) event.
The HCI command is specified by the Opcode, any arbitrary is supported
including vendor commands, but contrary to the like of
Raw/User channel it is run as an HCI command send by the kernel
since it uses its command synchronization thus it is possible to wait
for a specific event as a response.
Setting event to 0x00 will cause the command to wait for either
HCI Command Status or HCI Command Complete.
Timeout is specified in seconds, setting it to 0 will cause the
default timeout to be used.
Possible errors: Failed
Invalid Parameters
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
Syzbot has reported the following KASAN splat:
BUG: KASAN: slab-use-after-free in device_for_each_child+0x18f/0x1a0
Read of size 8 at addr ffff88801f605308 by task kbnepd bnep0/4980
CPU: 0 UID: 0 PID: 4980 Comm: kbnepd bnep0 Not tainted 6.12.0-rc4-00161-gae90f6a6170d #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x100/0x190
? device_for_each_child+0x18f/0x1a0
print_report+0x13a/0x4cb
? __virt_addr_valid+0x5e/0x590
? __phys_addr+0xc6/0x150
? device_for_each_child+0x18f/0x1a0
kasan_report+0xda/0x110
? device_for_each_child+0x18f/0x1a0
? __pfx_dev_memalloc_noio+0x10/0x10
device_for_each_child+0x18f/0x1a0
? __pfx_device_for_each_child+0x10/0x10
pm_runtime_set_memalloc_noio+0xf2/0x180
netdev_unregister_kobject+0x1ed/0x270
unregister_netdevice_many_notify+0x123c/0x1d80
? __mutex_trylock_common+0xde/0x250
? __pfx_unregister_netdevice_many_notify+0x10/0x10
? trace_contention_end+0xe6/0x140
? __mutex_lock+0x4e7/0x8f0
? __pfx_lock_acquire.part.0+0x10/0x10
? rcu_is_watching+0x12/0xc0
? unregister_netdev+0x12/0x30
unregister_netdevice_queue+0x30d/0x3f0
? __pfx_unregister_netdevice_queue+0x10/0x10
? __pfx_down_write+0x10/0x10
unregister_netdev+0x1c/0x30
bnep_session+0x1fb3/0x2ab0
? __pfx_bnep_session+0x10/0x10
? __pfx_lock_release+0x10/0x10
? __pfx_woken_wake_function+0x10/0x10
? __kthread_parkme+0x132/0x200
? __pfx_bnep_session+0x10/0x10
? kthread+0x13a/0x370
? __pfx_bnep_session+0x10/0x10
kthread+0x2b7/0x370
? __pfx_kthread+0x10/0x10
ret_from_fork+0x48/0x80
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK>
Allocated by task 4974:
kasan_save_stack+0x30/0x50
kasan_save_track+0x14/0x30
__kasan_kmalloc+0xaa/0xb0
__kmalloc_noprof+0x1d1/0x440
hci_alloc_dev_priv+0x1d/0x2820
__vhci_create_device+0xef/0x7d0
vhci_write+0x2c7/0x480
vfs_write+0x6a0/0xfc0
ksys_write+0x12f/0x260
do_syscall_64+0xc7/0x250
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 4979:
kasan_save_stack+0x30/0x50
kasan_save_track+0x14/0x30
kasan_save_free_info+0x3b/0x60
__kasan_slab_free+0x4f/0x70
kfree+0x141/0x490
hci_release_dev+0x4d9/0x600
bt_host_release+0x6a/0xb0
device_release+0xa4/0x240
kobject_put+0x1ec/0x5a0
put_device+0x1f/0x30
vhci_release+0x81/0xf0
__fput+0x3f6/0xb30
task_work_run+0x151/0x250
do_exit+0xa79/0x2c30
do_group_exit+0xd5/0x2a0
get_signal+0x1fcd/0x2210
arch_do_signal_or_restart+0x93/0x780
syscall_exit_to_user_mode+0x140/0x290
do_syscall_64+0xd4/0x250
entry_SYSCALL_64_after_hwframe+0x77/0x7f
In 'hci_conn_del_sysfs()', 'device_unregister()' may be called when
an underlying (kobject) reference counter is greater than 1. This
means that reparenting (happened when the device is actually freed)
is delayed and, during that delay, parent controller device (hciX)
may be deleted. Since the latter may create a dangling pointer to
freed parent, avoid that scenario by reparenting to NULL explicitly.
Reported-by: syzbot+6cf5652d3df49fae2e3f@syzkaller.appspotmail.com
Tested-by: syzbot+6cf5652d3df49fae2e3f@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=6cf5652d3df49fae2e3f
Fixes: a85fb91e3d72 ("Bluetooth: Fix double free in hci_conn_cleanup")
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
Have exception event part of HCI traces which helps for debug.
snoop traces:
> HCI Event: Vendor (0xff) plen 79
Vendor Prefix (0x8780)
Intel Extended Telemetry (0x03)
Unknown extended telemetry event type (0xde)
01 01 de
Unknown extended subevent 0x07
01 01 de 07 01 de 06 1c ef be ad de ef be ad de
ef be ad de ef be ad de ef be ad de ef be ad de
ef be ad de 05 14 ef be ad de ef be ad de ef be
ad de ef be ad de ef be ad de 43 10 ef be ad de
ef be ad de ef be ad de ef be ad de
Fixes: af395330abed ("Bluetooth: btintel: Add Intel devcoredump support")
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes
Short summary of fixes pull:
bridge:
- tc358768: Fix DSI command tx
nouveau:
- Fix GSP AUX error handling
- dp: Handle retires for AUX CH transfers with GSP
- fw: Sync DMA after setup
panthor:
- Fix partial BO mappings to GPU
rockchip:
- vop: Avoid null-ptr deref in plane-state check
vmwgfx:
- Avoid null-ptr deref in surface creation
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20241114142256.GA86810@2a02-2454-fd5e-fd00-4ce-489-4b34-bd1a.dyn6.pyur.net
|
|
Since 61a939c68ee0 ("Bluetooth: Queue incoming ACL data until
BT_CONNECTED state is reached") there is no long the need to call
mgmt_device_connected as ACL data will be queued until BT_CONNECTED
state.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=219458
Link: https://github.com/bluez/bluez/issues/1014
Fixes: 333b4fd11e89 ("Bluetooth: L2CAP: Fix uaf in l2cap_connect")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
Use devm_clk_get_optional() instead of hand writing it.
This saves some LoC and improves the semantic.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
Before issuing the LE BIG Create Sync command, an available BIG handle
is chosen by iterating through the conn_hash list and finding the first
unused value.
If a BIG is terminated, the associated hcons are removed from the list
and the LE BIG Terminate Sync command is sent via hci_sync queue.
However, a new LE BIG Create sync command might be issued via
hci_send_cmd, before the previous BIG sync was terminated. This
can cause the same BIG handle to be reused and the LE BIG Create Sync
to fail with Command Disallowed.
< HCI Command: LE Broadcast Isochronous Group Create Sync (0x08|0x006b)
BIG Handle: 0x00
BIG Sync Handle: 0x0002
Encryption: Unencrypted (0x00)
Broadcast Code[16]: 00000000000000000000000000000000
Maximum Number Subevents: 0x00
Timeout: 20000 ms (0x07d0)
Number of BIS: 1
BIS ID: 0x01
> HCI Event: Command Status (0x0f) plen 4
LE Broadcast Isochronous Group Create Sync (0x08|0x006b) ncmd 1
Status: Command Disallowed (0x0c)
< HCI Command: LE Broadcast Isochronous Group Terminate Sync (0x08|0x006c)
BIG Handle: 0x00
This commit fixes the ordering of the LE BIG Create Sync/LE BIG Terminate
Sync commands, to make sure that either the previous BIG sync is
terminated before reusing the handle, or that a new handle is chosen
for a new sync.
Fixes: eca0ae4aea66 ("Bluetooth: Add initial implementation of BIS connections")
Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
This removes the kzalloc memory allocation inside critical section in
create_pa_sync, fixing the following message that appears when the kernel
is compiled with CONFIG_DEBUG_ATOMIC_SLEEP enabled:
BUG: sleeping function called from invalid context at
include/linux/sched/mm.h:321
Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
This make use of kref to keep track of reference of iso_conn which
allows better tracking of its lifetime with usage of things like
kref_get_unless_zero in a similar way as used in l2cap_chan.
In addition to it remove call to iso_sock_set_timer on iso_sock_disconn
since at that point it is useless to set a timer as the sk will be freed
there is nothing to be done in iso_sock_timeout.
Fixes: ccf74f2390d6 ("Bluetooth: Add BTPROTO_ISO socket type")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
This make use of kref to keep track of reference of sco_conn which
allows better tracking of its lifetime with usage of things like
kref_get_unless_zero in a similar way as used in l2cap_chan.
In addition to it remove call to sco_sock_set_timer on __sco_sock_close
since at that point it is useless to set a timer as the sk will be freed
there is nothing to be done in sco_sock_timeout.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
Zephyr(1) has been using the same bus defines as Linux so tools likes of
btmon, etc, are able to decode the bus used by the driver to transport
HCI packets.
Link: https://github.com/zephyrproject-rtos/zephyr/pull/80808
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
Add below HWIDs for MediaTek MT7925 USB Bluetooth chip.
VID 0x0489, PID 0xe14f
VID 0x0489, PID 0xe150
VID 0x0489, PID 0xe151
Patch has been tested successfully and controller is recognized
device pair successfully.
MT7925 module bring up message as below.
Bluetooth: Core ver 2.22
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP socket layer initialized
Bluetooth: SCO socket layer initialized
Bluetooth: hci0: HW/SW Version: 0x00000000, Build Time: 20240816133202
Bluetooth: hci0: Device setup in 286558 usecs
Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported.
Bluetooth: hci0: AOSP extensions version v1.00
Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Bluetooth: BNEP filters: protocol multicast
Bluetooth: BNEP socket layer initialized
Bluetooth: MGMT ver 1.22
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM ver 1.11
Signed-off-by: Jiande Lu <jiande.lu@mediatek.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
Add VID 0489 & PID e124 for MediaTek MT7925 USB Bluetooth chip.
The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.
T: Bus=01 Lev=01 Prnt=01 Port=08 Cnt=02 Dev#= 3 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e124 Rev= 1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
S: SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 3 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= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=8a(I) Atr=03(Int.) MxPS= 64 Ivl=125us
E: Ad=0a(O) Atr=03(Int.) MxPS= 64 Ivl=125us
I: If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
Signed-off-by: Jonathan McCrohan <jmccrohan@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
Currently, hci_conn_hash_lookup_big only checks for BIS master connections,
by filtering out connections with the destination address set. This commit
updates this function to also consider BIS slave connections, since it is
also used for a Broadcast Receiver to set an available BIG handle before
issuing the LE BIG Create Sync command.
Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
The Bluetooth Core spec does not allow a LE BIG Create sync command to be
sent to Controller if another one is pending (Vol 4, Part E, page 2586).
In order to avoid this issue, the HCI_CONN_CREATE_BIG_SYNC was added
to mark that the LE BIG Create Sync command has been sent for a hcon.
Once the BIG Sync Established event is received, the hcon flag is
erased and the next pending hcon is handled.
Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
Currently, when a BIS slave connection is notified to the
ISO layer, the parent socket is tried to be matched by the
HCI_EVT_LE_BIG_SYNC_ESTABILISHED event. However, a BIS slave
connection is notified to the ISO layer after the Command
Complete for the LE Setup ISO Data Path command is received.
This causes the parent to be incorrectly matched if multiple
listen sockets are present.
This commit adds a fix by matching the parent based on the
BIG handle set in the notified connection.
Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
The Bluetooth Core spec does not allow a LE PA Create sync command to be
sent to Controller if another one is pending (Vol 4, Part E, page 2493).
In order to avoid this issue, the HCI_CONN_CREATE_PA_SYNC was added
to mark that the LE PA Create Sync command has been sent for a hcon.
Once the PA Sync Established event is received, the hcon flag is
erased and the next pending hcon is handled.
Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
The original timeout setting for HCI Reset on shutdown is 10 seconds.
HCI Reset shouldn't take 10 seconds to complete so instead use the
default timeout for commands.
Signed-off-by: Hilda Wu <hildawu@realtek.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
